Industrial robot digital twin real-time driving method based on hierarchical decoupling architecture

Abstract

The application discloses an industrial robot digital twin real-time driving method based on a layered decoupling architecture, which comprises the following steps: constructing a layered decoupling architecture, and adopting a database connection pool and an exponential backoff retry mechanism to realize high-concurrency asynchronous data access; utilizing hysteresis detection and a dynamic reading quantity adjustment strategy to complete accurate data calibration; performing deduplication, caching, angle correction and intermediate frame insertion processing on joint angle data; combining a sliding window performance monitoring and a disturbance feature vector to dynamically switch a motion mode, thereby realizing smooth driving of a virtual robot arm; supporting accurate segmentation of historical data and multi-device synchronous playback, and having full-link thread safety mechanism and parameter configurable capability, thereby being suitable for multiple types of robot arms and heterogeneous industrial environments. The application realizes millisecond-level synchronization of a physical robot arm and a virtual twin model, effectively solves the shortcomings of existing methods in terms of expansibility, synchronization accuracy and stability in complex working conditions, and is suitable for industrial scenes such as human-robot collaborative assembly.

Description

Technical Field

[0001] This invention relates to the field of industrial digital twin technology, specifically to a real-time driving method for industrial robotic arms based on a hierarchical decoupling architecture. Background Technology

[0002] In the field of industrial human-machine collaborative assembly, digital twin technology has become a core means of connecting physical production equipment with virtual simulation models. Real-time driving of the digital twin of an industrial robotic arm is a key link in realizing the digitization and visualization of the assembly process. Most existing digital twin driving methods adopt a tightly coupled architecture, with high coupling between data acquisition, processing, and rendering stages, resulting in poor system scalability and maintenance difficulties. Furthermore, during real-time data driving, due to factors such as network latency, database read bottlenecks, and rendering frame rate fluctuations, problems such as virtual robotic arm movement stuttering, jumps, and desynchronization with the actual equipment often occur. Traditional methods have weak adaptability to various types of robotic arms, making it difficult to meet the rapid deployment requirements of flexible manufacturing scenarios. To address these issues, there is an urgent need for a layered, decoupled, high-concurrency, and adaptive real-time driving method for industrial robotic arm digital twins, achieving millisecond-level synchronization between the physical robotic arm and the virtual twin model, while supporting motion backtracking, multi-device collaboration, and adaptation to heterogeneous industrial environments. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a real-time driving method for digital twins of industrial robotic arms based on a hierarchical decoupling architecture. By using a hierarchical decoupling architecture and an adaptive data pipeline, it solves the problems of poor system scalability, stuttering and abrupt changes in virtual robotic arm movement, and low synchronization accuracy with physical devices caused by tight coupling of the architecture and rigid data processing in existing digital twin driving methods.

[0004] Technical solution:

[0005] A real-time driving method for digital twins of industrial robotic arms based on a hierarchical decoupling architecture includes the following steps:

[0006] Step 1: Construct a layered and decoupled system architecture. The architecture includes functional layers for data acquisition and calibration, data processing and caching, performance monitoring, and model-driven functions, and realizes data interaction between layers through standardized interfaces.

[0007] Step 2: Asynchronously monitor the database at fixed intervals to obtain the joint angle data of the robotic arm; determine the data synchronization status through hysteresis detection, and dynamically adjust the data reading amount for the next cycle based on the hysteresis amount;

[0008] Step 3: Perform deduplication and verification on the acquired joint angle data, and detect and smooth abrupt changes in joint angles;

[0009] Step 4: Create a sliding window to collect real-time statistics on the system's performance metrics and construct a disturbance feature vector based on the performance metrics; based on the disturbance feature vector, dynamically determine and switch the motion mode of the virtual robotic arm, the motion mode including at least the JUMP mode with directly set angle and the normal mode with easing function interpolation;

[0010] Step 5: Based on the 3D engine, drive the virtual robotic arm and, according to the switched motion mode, perform direct angle setting or easing interpolation on the target joint angle data after the data processing and caching steps to control the joint movement of the virtual robotic arm.

[0011] Step 6: Asynchronously monitor process instructions and equipment status data at fixed intervals, and synchronously update the process execution status and IO status of the virtual robotic arm to achieve synchronization of process instructions and status.

[0012] Furthermore, in step 2, data acquisition and calibration, a database connection pool mechanism is used for asynchronous data access, and an exponential backoff retry strategy is configured for database operations.

[0013] Furthermore, in step 2, the method for adjusting the data read volume is as follows: calculate the latest record number in the database. With the latest record number processed locally The difference is used as a lag. , ;

[0014] If the hysteresis Exceeding the dynamic threshold calculated based on the current read volume, i.e. If this occurs, it is identified as a lagging disturbance, and the planned read volume for the next cycle is reduced. for ;

[0015] If no hysteresis disturbance occurs and the current read volume is less than the normal value, that is and At that time, increase the planned read volume for the next cycle. for In the formula, For dynamic threshold ratio, For the current read volume, This is normal read volume. Minimum read size, This is a single adjustment step size.

[0016] Furthermore, in step 3, the deduplication screening condition is: Let the first... The original joint data record is as follows ,in ,

[0017] ,in For the first The joint angle vector of each record. For the first The angle components of each joint in the frame, For the first One original joint data record, pending execution buffer. For the first The unique identifier of each record For the first The timestamp of the record The ID of the latest record processed in the system. The timestamp of the latest record processed in the system. For the processed set, a hash structure is used to maintain the eviction queue and data buffer pool.

[0018] Furthermore, in step 3, the joint direction correction matrix is ​​used. and model mounting bias vector Correct the joint angle data: The corrected angle data Add a buffer system; calculate the joint angle difference between adjacent frames in the buffer system, and when the angle difference exceeds a preset threshold, i.e. At that time, at least one intermediate frame is inserted by interpolation. In the formula, the subscript k,j represents the j-th joint of the k-th frame. This is the threshold for the angle difference.

[0019] Furthermore, performance metrics include average data arrival interval. Compared to the average system rendering frame interval ;when If the input state is high frequency, switch to the JUMP mode; otherwise, maintain or switch to the normal mode.

[0020] Furthermore, in the normal mode, the EaseInOutQuad easing function is used to perform smooth interpolation calculations on the joint angles of the virtual robotic arm. The formula for the EaseInOutQuad easing function is:

[0021] ,

[0022] In the formula, Indicates the interpolation progress coefficient; This represents normalized time.

[0023] Furthermore, the method also includes synchronous playback of historical data: motion segment detection is performed on historical joint angle data, and nodes with intervals exceeding a preset threshold are identified by detecting the time interval between adjacent data points, thereby dividing continuous motion data into multiple independent motion segments and recording start and end information; in multi-machine collaborative scenarios, the start time of a certain motion segment of the main robotic arm is set as the global reference time, so that other slave robotic arms can automatically locate the point at the same time in their own historical data after obtaining the reference time, and synchronously start the playback of historical actions with the main robotic arm based on this unified time point, so as to realize the collaborative reproduction of the historical operation process of multiple devices.

[0024] Furthermore, the method also includes process instruction monitoring and status synchronization: querying the core data table containing process instructions at fixed intervals to check and verify whether there are new process instructions, and then triggering the execution of a preset action sequence corresponding to the process instructions; at the same time, continuously monitoring the status signals and real-time information of IO changes generated by physical devices, and synchronizing the real-time information to the virtual twin model to ensure that the virtual model is consistent with the physical world in terms of business logic and operating status.

[0025] The core data tables include the process flow table, the handling robot data table, and the assembly robot data table. An asynchronous monitoring method for process instructions is run in a loop, periodically querying the three core data tables. It verifies whether the instruction trigger field in the data table has been assigned a value, and whether the current data row ID is greater than the last processed ID locally. If these conditions are met, it is determined to be a new process instruction; otherwise, it is determined that there is no new process instruction. After determining that it is a new process instruction, the process instruction information is called back to the main thread through the main thread scheduler, and the process instruction is issued.

[0026] The main thread scheduler consists of four components: task queue, main thread polling, instruction execution, and exception interception; the asynchronous monitoring method for process instructions includes four execution steps: periodic timing, multi-table query, instruction verification, and result return; after the process instruction is executed, the instruction issuance field in the data table is automatically cleared.

[0027] Furthermore, the method employs a full-link thread safety mechanism, including using a thread-safe collection class to manage shared data cache; implementing asynchronous submission and writing of logs through a thread-safe queue; and ensuring that all calls to the 3D engine interface are executed on the main thread through the main thread scheduler.

[0028] Beneficial effects:

[0029] (1) The real-time driving method for digital twins of industrial robotic arms based on a layered decoupling architecture disclosed in this invention adopts a nine-layer layered decoupling architecture, a combination of hysteresis detection and dynamic read adjustment, motion segment detection and master-slave synchronous backtracking, which solves the technical pain point that the existing tightly coupled architecture cannot take into account synchronization, scalability and stability. Each part has a single responsibility and standardized interface, realizing architectural decoupling and strong scalability. Iterative upgrades of a single module do not require reconstruction of the entire system. It supports the adaptation of heterogeneous industrial environments with multiple types of robotic arms and multiple brand databases, and can be quickly extended to complex assembly scenarios with multi-device collaboration.

[0030] (2) The real-time driving method for digital twin of industrial robotic arm based on layered decoupling architecture disclosed in this invention adopts an asynchronous non-blocking data processing mode throughout the entire link. Combined with connection pool, thread-safe queue and batch processing mechanism, it realizes efficient processing of high-frequency joint angle data and achieves millisecond-level data synchronization between physical robotic arm and virtual model, effectively solving the problems of data accumulation and processing delay.

[0031] (3) The real-time driving method for digital twin of industrial robotic arm based on layered decoupling architecture disclosed in this invention designs a motion mode dynamic determination mechanism based on sliding window, and combines EaseInOutQuad easing interpolation and intermediate frame adaptive insertion algorithm to automatically switch motion modes according to data rate and rendering frame rate, so as to avoid the virtual robotic arm from stuttering or jumping, and accurately restore the continuous motion state of physical equipment.

[0032] (4) The real-time driving method for digital twin of industrial robotic arms based on a hierarchical decoupling architecture disclosed in this invention proposes an intelligent detection algorithm for motion segments and a synchronous backtracking mechanism between master and slave robotic arms. It can automatically segment historical motion data, realize synchronous playback of multiple devices based on reference time, and support breakpoint resume transmission, providing accurate digital support for fault tracing in the assembly process. Combining the dual judgment mechanism of timestamp and angle change, the segmentation accuracy is higher than that of traditional time segmentation methods, and fault nodes in the assembly process can be accurately located.

[0033] (5) The real-time driving method for digital twin of industrial robotic arm based on layered decoupling architecture disclosed in this invention designs a lag detection and dynamic read volume adjustment strategy. When data lag occurs between the database and the local system, the cache is automatically cleared and the read volume is adjusted to avoid data loss or duplicate processing. Combined with asynchronous retry, connection pool reconstruction, query mode switching and other mechanisms, the stability and reliability of the system in complex industrial environments are greatly improved.

[0034] (6) The real-time driving method of digital twin of industrial robotic arm based on layered decoupling architecture disclosed in this invention realizes real-time monitoring of performance indicators such as data rate, frame time, and processing latency. Combined with JSON formatted storage of multiple types of asynchronous logs, it supports the visualization analysis of system operation status and rapid problem location, effectively improving the maintainability of the system.

[0035] (7) The real-time driving method for digital twin of industrial robotic arm based on layered decoupling architecture disclosed in this invention configures dedicated lock objects and concurrent sets for core data resources, ensures safe calls to the 3D engine API through the main thread scheduler, realizes thread safety and high concurrency adaptation, and supports the high-frequency and high-throughput data processing needs of industrial sites. Attached Figure Description

[0036] Figure 1 This is an overall flowchart of the present invention;

[0037] Figure 2 This is a schematic diagram of data interaction in this invention;

[0038] Figure 3 This is a schematic diagram of the database connection pool working mechanism of the present invention;

[0039] Figure 4 This is a schematic diagram of the data acquisition and calibration layer monitoring process of the present invention;

[0040] Figure 5 This is a schematic diagram of the data processing and caching layer architecture and queuing process of the present invention;

[0041] Figure 6 This is a schematic diagram illustrating the feature vector construction and interpolation mode determination of the present invention;

[0042] Figure 7 This is a schematic diagram of the easing interpolation driving method of the present invention;

[0043] Figure 8 This is a schematic diagram illustrating the asynchronous non-blocking log classification storage and batch writing of the present invention;

[0044] Figure 9 This invention relates to a multi-device status monitoring and process instruction loop control process.

[0045] Figure 10 This is a schematic diagram of the synchronous playback process of the master-slave robotic arm in the backtracking driving layer of the present invention;

[0046] Figure 11 This is a schematic diagram of the end-to-end thread safety mechanism of the present invention;

[0047] Figure 12 The data transmission and processing efficiency statistics are shown in the example for verification.

[0048] Figure 13The system used as a verification example performs real-time statistics on the motion data of the assembly robot.

[0049] Figure 14 This serves as the data management interface for a verification example.

[0050] Figure 15 shows the process execution time monitoring of the verification example, where Figure 15(1) is a diagram of the process execution time analysis of the transport robot, and Figure 15(2) is a diagram of the process execution time analysis of the assembly robot.

[0051] Figure 16 shows the backtracking control interface of the verification example, where Figure 16(1) is the historical data backtracking control panel interface and Figure 16(2) is the running status monitoring and log display interface.

[0052] Figure 17 shows the actual operating status of the verification example on the experimental assembly workbench. Figure 17(1) shows the monitoring interface for the fusion of the operating status and the virtual and real perspectives. Figure 17(2) shows the monitoring interface for process execution and multi-view linkage. Figure 17(3) shows the interface for visual inspection feedback and processing results display. Specific implementation methods

[0053] The present invention will now be described in detail with reference to the accompanying drawings.

[0054] Example 1:

[0055] As attached Figures 1 to 11 As shown, the real-time driving method for digital twins of industrial robotic arms based on a hierarchical decoupling architecture includes:

[0056] I. Build and initialize the system

[0057] (1) Construct a layered and decoupled architecture from the underlying data interaction to the upper-level visualization display.

[0058] In this embodiment, the system is designed with a nine-layer architecture, from top to bottom: the upper layer consists of an application presentation layer and a model-driven layer; the middle layer is a data processing layer, including a data processing and caching layer, a data acquisition and calibration layer, a performance monitoring layer, a database connection layer, and a log and data recording layer; and the lower layer is a process control layer and a backtracking-driven layer. Data interaction between layers is achieved through standardized interfaces.

[0059] The application presentation layer is responsible for the final visualization rendering and presentation of the virtual robotic arm model, equipment status, performance indicators, and other content, to achieve an immersive display;

[0060] The model-driven layer, as the core engine driving the movement of the virtual robotic arm, receives the processed data and performs direct setting or smooth interpolation calculation of joint angles.

[0061] The data processing and caching layer performs deduplication, caching, angle correction and smoothing (such as inserting intermediate frames) on the joint angle data to form a target data queue that can be directly used for driving.

[0062] The data acquisition and calibration layer listens to and queries the database at fixed intervals to obtain raw joint data, and achieves accurate and synchronous calibration of the data through strategies such as hysteresis detection and dynamic adjustment of reading volume.

[0063] The performance monitoring layer creates a sliding window to collect real-time statistics on key system performance indicators (such as data interval and frame time), and constructs a perturbation feature vector based on this to provide a basis for decision-making for motion mode switching.

[0064] The database connection layer manages all database connections and achieves stable and efficient asynchronous data access in high-concurrency scenarios through mechanisms such as database connection pooling and exponential backoff retries.

[0065] The log and data recording layer is responsible for the classification, collection, asynchronous batch writing, and persistent storage of various types of system operation logs (real-time drive, performance monitoring, process status);

[0066] The process control layer listens to process instructions and synchronizes the IO signals, online status, and process progress of the PLC and the robotic arm to achieve synchronization of business process status between the physical and virtual systems.

[0067] The backtracking driver layer provides intelligent segmentation (motion segment detection) of historical motion data, master-slave device synchronous playback function, and supports fault backtracking and process reproduction.

[0068] In this embodiment, the complex digital twin system is divided into independent layers with single responsibilities according to function. Data interaction between layers is carried out through standardized interfaces, so that technical upgrades or modifications of any layer do not affect other layers, thereby improving the maintainability and scalability of the system.

[0069] (2) Establish system-level support mechanisms such as database connection pool, thread safety mechanism, and parameter configurability, and initialize basic services.

[0070] Based on a database connection pool mechanism, valid connections are returned to the pool, while invalid connections are destroyed directly. All database operations are equipped with an exponential backoff retry strategy (i.e., after a failure, the waiting time increases exponentially before retrying), ensuring stable and asynchronous data retrieval even under network fluctuations or database pressure (high concurrency scenarios).

[0071] The database connection pool mechanism aims to avoid the significant overhead of frequently creating and destroying database connections, improving performance and handling concurrent requests by reusing connections. It includes the following components:

[0072] A thread-safe queue is created to store available database connections; the maximum number of concurrent connections is controlled using semaphores to prevent resource overload. This mechanism provides an asynchronous connection acquisition interface that supports cancellation tokens and timeout control, and automatically checks the status of connections upon acquisition, immediately re-establishing any invalid connections. After data operations are completed, valid connections are returned to the connection pool for reuse, while invalid connections are destroyed, and the connection count in the pool is updated synchronously. Furthermore, during data submission operations, if the operation fails, an exponential backoff strategy is triggered for retries; if the retries ultimately fail, an exception is thrown and the corresponding log is logged.

[0073] The exponential backoff retry strategy is used to handle occasional operation failures caused by network jitter, sudden database pressure, etc. When a database query or write operation fails, the system does not immediately throw an error but automatically triggers a retry mechanism. "Exponential backoff" means that the waiting time between each retrieval increases exponentially (e.g., 100ms for the first retrieval, 200ms for the second, and 400ms for the third). This avoids a crash caused by a large number of requests retrying simultaneously during a brief database failure. If the retries still fail after exceeding a preset number, it is considered a persistent failure, at which point an exception is thrown, and detailed error information is logged for subsequent troubleshooting.

[0074] A full-chain thread safety mechanism is designed, including locking mechanisms for data caching, thread-safe queues for log writing, and main thread scheduling for 3D engine calls, employing thread-safe collections such as thread-safe queues and thread-safe dictionaries. The main thread scheduler ensures that the 3D engine interface executes only on the main thread; a singleton database management system manages multiple database configurations; an event callback interface is designed in the process control layer; and core parameters are made configurable to support dynamic adjustments in industrial settings.

[0075] The thread safety mechanism includes data caching, log writing, and ID update throughout the entire process; it employs thread-safe queues, thread-safe dictionaries, and other thread-safe collections, and ensures that the 3D engine application programming interface executes only on the main thread through the main thread scheduler; it manages multiple database configurations through a single database management instance, compatible with heterogeneous industrial databases such as process management, assembly robotic arms, and handling robotic arms; the database management instance includes four functional units: instance creation, multi-configuration loading, connection management, and operation encapsulation; the process control layer is designed with a numerical update event callback interface, supporting real-time monitoring of equipment status changes and custom business extensions; core parameters such as data read volume, cache capacity, calibration interval, and query cycle are set as configurable items and dynamically adjusted according to the industrial site.

[0076] (3) Initialize the log system.

[0077] Under a layered, decoupled architecture, an asynchronous, non-blocking operation mode is adopted to complete the classification, storage, batch writing, and fault tolerance handling of various types of system logs. Specifically, this includes:

[0078] The system logs are divided into three categories: real-time drive logs, performance monitoring logs, and process status logs. These logs record data such as the joint angle of the robotic arm, system performance indicators (such as the average data interval, average frame time, processing delay, motion mode, etc. generated in step 5), and the execution status of the assembly process (such as PLC / robotic arm IO signals, online status, instruction triggering and completion, and other business logic information).

[0079] By adding log information to a thread-safe log queue through a log file writing interface, log recording operations are ensured not to block the real-time data-driven and motion rendering main threads, thus decoupling log submission from core business processing. When the business layer needs to write logs, it does not directly manipulate the file, but instead calls a unified logging interface to immediately append the log information (usually formatted as a JSON object) to a thread-safe queue. The business layer can then return immediately after the call and continue processing subsequent business logic.

[0080] When the log queue accumulates to the specified number of entries or exceeds the specified time, a background thread for writing logs in a loop is started, which writes the queue logs to the file in batches using an asynchronous log refresh method.

[0081] In this embodiment, a separate background thread is responsible for monitoring the log queue. There are two conditions that trigger batch writing; either condition must be met:

[0082] Quantity trigger: The number of log entries accumulated in the queue reaches a set value;

[0083] Time-triggered: The time interval since the last write exceeds the set value.

[0084] When the triggering conditions are met, the background thread retrieves a batch of logs accumulated in the queue and writes them asynchronously and in batches to a disk file. If a batch write to disk fails (e.g., the disk is full), the system does not discard these logs. Instead, it puts these logs back to the head of the queue, waiting to try again in the next write cycle. All logs are stored using JSON format encoding.

[0085] II. Real-time Synchronization Operation Process

[0086] After the system starts, the real-time synchronization between the physical robotic arm and the virtual model is achieved according to the following process:

[0087] (1) Intelligent data synchronization sub-process:

[0088] First, based on the auto-incrementing characteristic of database records (i.e., when a new record is inserted into the table, the database automatically generates a unique, incrementing ID for that record), the system actively queries the database at a fixed period to obtain the latest robotic arm joint angle data. Simultaneously, combined with a timed calibration mechanism, the system determines the data synchronization status through lag detection, dynamically adjusts the data read volume, and switches query modes to complete precise data calibration.

[0089] Specifically, it includes:

[0090] (a) The asynchronous listening main loop interface is used as the standardized real-time entry point for reading joint angle data from the database, with a preset query period of [missing information]. The database is queried according to a preset query period and ID range to obtain the latest robotic arm joint angle data.

[0091] (b) Set the calibration interval. Each time calibration is triggered, time calibration and dynamic reading adjustment will be performed.

[0092] (c) The system continuously compares the latest data ID in the database with the latest data ID processed locally, and calculates the lag. The lag is defined as:

[0093]

[0094] In the above formula, The latest record number in the database. This is the latest record number that has been processed locally. Consider different read scales. The system's hysteresis tolerance is adjusted by introducing a dynamic threshold ratio. .

[0095] when If the data is detected as a lagging disturbance, it indicates that data processing cannot keep up with the acquisition speed. In this case, the system clears the local cache and jumps directly to the latest data to prevent a cascading failure. Simultaneously, the amount of data queried in the next round is dynamically reduced. Adjusted to Once the system catches up, gradually increase the query volume until it returns to normal. Finally, update the locally processed IDs and timestamps.

[0096] when and At that time, the next cycle read volume will be... Adjusted to .

[0097] Based on the current lag, determine the next round of reads. The adjustment can be summarized as follows:

[0098]

[0099] in This is normal read volume. Minimum read size, The adjustment step size is set to a single step; if hysteresis is detected, the reading is reduced each time. If there is no lag and the read volume has not recovered to the initial value, then each increment... The maximum number of reads is .

[0100] (d) The preset wait mode trigger count is The safe mode trigger count is The safe mode query cycle is If no new data is added, the count is ≥ If no new data is found, it enters waiting mode and continues fast polling; if the count is greater than or equal to 1, it will enter waiting mode. If this happens, the system will enter safe mode and the query cycle will be changed from [previous time]. Adjusted to This is to reduce system resource consumption.

[0101] Then, the acquired joint angle data undergoes deduplication, caching, and smoothing. This includes: performing double verification on newly acquired data, adding it to the caching system after successful verification; removing the oldest data when the eviction queue or buffer pool capacity exceeds its limit; and detecting the joint angle difference between adjacent frames, inserting an intermediate frame if any axis angle difference changes abruptly. Specifically, this includes:

[0102] (a) Establish a deduplication check mechanism for processed IDs to verify newly acquired data, ensuring that every piece of data entering the processing pipeline is new, unique, and sequentially correct, avoiding duplicate processing of the same data due to network retransmissions, overlapping listening cycles, etc. Let the... The original joint data record is as follows , among which is Auto-incrementing ID It's a timestamp. It consists of 6 angle vectors for the joints. The deduplication criteria are:

[0103]

[0104] in This is a buffer for execution. For the processed set, a hash structure is used to maintain the eviction queue and data buffer pool. Only data that simultaneously meets the following conditions is considered eviction: ID incrementing (verification data ID is greater than the last processed ID locally), timestamp incrementing (timestamp is greater than the last processed time locally), and has not been processed. Only then will it be placed in the execution buffer. This deduplication mechanism ensures the uniqueness and strict timing of the data stream.

[0105] (b) To balance the difference between data processing speed and rendering speed, a data buffer is provided to prevent unlimited memory growth. This embodiment employs a dual-buffer structure: a data buffer pool stores data that has undergone verification and angle correction; a target queue to be executed stores smoothed data that will be sent to the driver layer. New data is added to the cache system after passing the verification in step 401. Capacity limits are set for the eviction queue and buffer pool; when the capacity exceeds the limit, the oldest data is removed.

[0106] (c) Perform angle correction and motion smoothing to resolve the model differences between the virtual model and the actual robotic arm and avoid abrupt changes in the virtual model.

[0107] First, the buffer pool data is corrected for angle:

[0108]

[0109] Expanded by joint components:

[0110]

[0111] In the above formula, This is the joint direction correction matrix. By installing a bias vector into the model, the above correction formula can modify the original data. Converted into angles that can directly drive the joints of the virtual model .

[0112] Then, mutation detection is performed, and the corrected data between adjacent frames is calculated. and Between these points, the maximum absolute value of the angle difference among the six joints, and the condition for abrupt change in the angle difference along any axis are:

[0113]

[0114] in It is a preset mutation threshold.

[0115] If the above abrupt change conditions are met, it indicates that any joint has experienced a sudden angle change between two adjacent frames. For smooth motion, the system... and Between these points, intermediate frames are inserted using linear interpolation to generate smooth target data to be executed. The intermediate frames are as follows:

[0116]

[0117] This newly generated intermediate frame will be added to the queue of targets to be executed.

[0118] (2) Adaptive decision-making and driving sub-process:

[0119] First, a sliding window with a fixed window size is created to collect system performance metrics in real time; the motion mode is dynamically determined and switched based on the perturbation feature vector; and the performance metrics are pushed to the log layer for visual monitoring.

[0120] This step, located between the data processing layer and the model-driven layer, monitors the system's real-time operating status and automatically selects the optimal motion interpolation strategy based on a data-driven approach. This addresses the issue of virtual model motion stuttering or desynchronization caused by a mismatch between the data reception rate and the rendering frame rate. Specifically:

[0121] System performance metrics include data interval, frame time, and processing latency. First, a sliding window is created to calculate the average data interval, average frame time, and average processing latency. The perturbation feature vector is then defined.

[0122]

[0123] In the above formula, For the average data interval, To average the refresh interval, To average processing latency, This is a count value indicating whether the data stream has been interrupted due to a continuous lack of new data. In the formula, , Specifically:

[0124] ,

[0125] In the above formula, This is the length of the sliding window.

[0126] when When the average interval between data arrivals is shorter than the average time to render a frame, it's considered a high-frequency input state. If smooth interpolation is still performed every frame, it will lead to rendering queue accumulation, causing virtual model movements to lag significantly behind physical entities. Therefore, the system automatically switches to JUMP mode, skipping interpolation and directly setting the target angle of the virtual model. This step prioritizes minimizing synchronization latency, avoiding slow-motion ghosting. Otherwise, normal interpolation mode is maintained, using easing functions for smooth interpolation to achieve optimal visual smoothness. Relevant performance metrics are pushed to the log and data recording layer in real time.

[0127] Then, based on a 3D engine, virtual robotic arm joint motion drive is implemented. Target data is batch-processed and expired data is filtered, with intermediate frames inserted as needed. After starting the motion coroutine, either direct angle setting or EaseInOutQuad easing functions are executed to achieve smooth interpolation according to the determined motion mode. Joint rotation axis parameters for different robotic arm types are configured. Specifically, this includes:

[0128] (a) Provide a batch processing interface for virtual robotic arm target data processing, read multiple target data at once, perform timestamp verification, and discard expired data.

[0129] (b) Perform angle difference detection on the batch data again. When the angle difference exceeds the preset threshold, insert an intermediate frame again to ensure that the data sequence sent to the motion actuator is smooth.

[0130] (c) Provide a motion coroutine startup interface as a standardized execution entry point for triggering joint movements of the virtual robotic arm. Starting this coroutine will call the single-frame motion control interface of the virtual robotic arm, which serves as the core underlying functional interface for motion driving. This underlying interface encapsulates the standardized single-frame joint motion control implementation logic.

[0131] (d) Based on the determined motion pattern, select different algorithms to drive the virtual robotic arm.

[0132] In JUMP mode, the target angle is set directly, meaning the motion coroutine sets the angles of the six joints of the virtual robotic arm to the angle values ​​of the current target data frame all at once.

[0133] For normal interpolation mode, the EaseInOutQuad easing function is used to achieve smooth interpolation. The easing function formula is as follows:

[0134]

[0135] In the above formula, Indicates the interpolation progress coefficient; This represents normalized time.

[0136] (e) Configure the rotation axis parameters of the 6 joints according to the type of robotic arm. The driving logic reads this configuration and correctly applies the calculated joint angles to the corresponding transformation nodes of the 3D model, thus achieving adaptive driving for multiple types of robotic arms.

[0137] (3) Business status synchronization sub-process:

[0138] To achieve synchronization between the virtual twin system and the physical production system at the business process level.

[0139] First, an asynchronous instruction listening loop is used to periodically and synchronously query three core data tables: the process flow table, the handling robot data table, and the assembly robot data table.

[0140] For each query result, the system performs a validation to determine if a new instruction has been triggered: first, it checks whether the instruction trigger field in the data table has been assigned a value, and second, it confirms that the ID of the current data row is greater than the last processed ID of the local record. Only when both conditions are met does the system determine that a new process instruction has been triggered.

[0141] Once a new instruction is detected, the listening mechanism does not process it directly. Instead, it uses a main thread scheduler to call back the task containing the instruction information to the main thread. This scheduler consists of four parts working together: a task queue, main thread polling, instruction execution, and exception interception. This ensures that all operations involving user interface or 3D scene state updates can be safely completed on the main thread, thus issuing the procedure instructions.

[0142] After the instruction is executed in the virtual environment, the system clears the corresponding instruction issuance field in the data table to complete the confirmation loop of instruction execution. At the same time, this step also continuously monitors the IO signals, online status, and process execution progress of physical devices (such as PLCs and robotic arms), and feeds these statuses back to the twin model in real time, ultimately achieving synchronization between the physical devices and the virtual model in terms of multiple devices and all dimensions of status.

[0143] III. Historical Retrospective Extended Function Mode

[0144] To achieve synchronization and playback of historical motion data, a motion segment detection algorithm is first used to traverse the historical joint angle data by timestamp. When the time difference between adjacent data exceeds a preset threshold, it is determined as a segmentation point of a motion segment, and the start and end information of each segment is recorded. When multi-machine collaborative playback is required, the start time of a certain motion segment of the master robotic arm is set as the global reference time. After obtaining this reference time, the robotic arm locates the corresponding moment in its own historical data and clears the real-time data cache to switch to playback mode. Subsequently, based on this unified reference time, the master and slave robotic arms synchronously start their respective historical data playback and call the same motion logic as the real-time drive (i.e., the interpolation algorithm in step 6) to drive the virtual model, thereby achieving accurate synchronous reproduction of the historical actions of multiple devices. Specifically, this includes:

[0145] (a) The long-term, continuous historical data stream is intelligently divided into meaningful independent "motion segments" based on the actual working intervals of the equipment.

[0146] Run the asynchronous motion segment detection algorithm, traversing historical joint angle data sorted by timestamp. The asynchronous motion segment detection algorithm includes four execution steps: data sorting, time difference calculation, segmentation point determination, and motion segment recording. The time difference is calculated using the following formula:

[0147]

[0148] In the above formula, The time difference between adjacent data. This is the current data timestamp. This is the timestamp of the previous data. A point exceeding the specified time is considered a motion segment breakpoint, meaning the robotic arm stopped for more than the threshold time between two movements, which can be considered two independent work cycles. The start and end IDs and times of each motion segment are recorded to complete the structured segmentation of historical data.

[0149] (b) In a multi-machine collaborative scenario, a unified time reference is established for synchronized playback of all devices. When a user selects a motion segment of the main robotic arm for playback, the system extracts the start timestamp of that motion segment and saves it as a global reference time through the local storage module. This time point will become the starting point of the entire synchronized playback process.

[0150] (c) Ensure that the playback starts at the same absolute point in time as the main robotic arm and clear irrelevant real-time data cache to avoid conflicts between playback data and real-time data.

[0151] The robotic arm reads the aforementioned global reference time, and the corresponding historical data for that time node is located and the local cache is cleared using a synchronous data positioning and cleaning method. This synchronous data positioning and cleaning method includes four execution steps: reference time reading, historical data matching, cache clearing, and positioning marking.

[0152] (d) The master and slave robotic arms start historical data playback based on the same reference time, and reuse the easing interpolation logic of the model driving layer in step 6 (including batch processing, interpolation mode determination, and EaseInOutQuad easing interpolation algorithm) to achieve synchronous movement. The playback process supports pause and resume operation, and realizes breakpoint resume based on the current playback timestamp, which can accurately locate the fault nodes in the assembly process.

[0153] IV. Achieving Visualization

[0154] Based on a 3D engine, the virtual robotic arm model is rendered, and the equipment's operating status and system performance indicators are presented in an immersive visualization, enabling a synchronized display of the entire physical assembly site and the virtual twin scene.

[0155] Example 2:

[0156] This embodiment is applied to a human-robot collaborative assembly scenario, adapting to two Elite industrial robotic arms: a transport robotic arm (ShippingJXB) and an assembly robotic arm (AssemblyJXB). Joint angle data is stored in a MySQL database, and Unity3D is used as the virtual visualization engine to achieve real-time driving and replay of the digital twins of the two robotic arms. The specific implementation steps are as follows:

[0157] 1. Construct a layered, decoupled architecture

[0158] This embodiment uses Unity3D as the virtual visualization engine and C# to implement a layered, decoupled architecture for the real-time driving of a digital twin of an industrial robotic arm. A nine-layer architecture is constructed, from bottom to top: application presentation layer, model-driven layer, data processing and caching layer, data acquisition and calibration layer, performance monitoring layer, database connection layer, logging and data recording layer, process control layer, and backtracking-driven layer. Data interaction between layers is achieved through standardized interfaces. The application presentation layer uses Unity3D to visualize the 3D model of the robotic arm and render the virtual scene, while the model-driven layer uses C# coroutines to control joint motion. Figure 2 The middle section is a data interaction diagram for this implementation case.

[0159] 2. Database connection pool and exponential backoff retry mechanism

[0160] This implementation uses a database connection pool mechanism and an exponential backoff retry strategy to achieve stable asynchronous data access in high-concurrency scenarios. The implementation uses a MySQL database to build a connection pool management mechanism, employing a C# `ConcurrentQueue` thread-safe queue to store available database connections. A `SemaphoreSlim` semaphore controls the maximum number of concurrent connections, with a default threshold of 20. An asynchronous connection acquisition interface `GetConnectionAsync` is provided. When acquiring a connection, the connection status is automatically checked. After data operations are completed, valid connections are returned to the connection pool, while invalid connections are destroyed and the connection count in the pool is updated synchronously. When performing database operations, if the operation fails, an exponential backoff retry is triggered. In this implementation, the maximum number of retries is 3, with a backoff delay of 100ms × 2ⁿ, where n is the number of retries. An exception is thrown and logged upon retry failure. Figure 3 The diagram below illustrates the working mechanism of the database connection pool in this implementation case.

[0161] 3. Asynchronous listening, lag detection, and dynamic read volume adjustment

[0162] The asynchronous listening main loop interface serves as the standardized real-time entry point for reading joint angle data from the database, and queries according to a preset cycle. This example queries data within an ID range; the default query period is 100ms, and the ID query range is [lastId, lastId+N]. A calibration interval is set; each calibration trigger performs time calibration and dynamic read volume adjustment; in this example, the calibration interval is 100 queries. Lag is calculated and a dynamic threshold ratio is introduced; the read volume for the next round is adjusted based on the current lag. (Appendix) Figure 4 The diagram below illustrates the data acquisition and calibration layer monitoring process in this implementation case.

[0163] In this embodiment, the hysteresis is calculated as follows:

[0164]

[0165] In the above formula, The latest record number in the database. Number the latest record that has been processed locally; consider different read scales. The system's hysteresis tolerance is adjusted by introducing a dynamic threshold ratio. ,when If the disturbance is identified as lagging, the local cache is cleared, and the system directly jumps to the latest data and updates the locally processed ID and timestamp. In this embodiment... It is a constant, set to 0.02.

[0166] In this embodiment, the next round of reads is based on the current lag. Adjustments will be made:

[0167]

[0168] in This is normal read volume. Minimum read size, The adjustment step size is set to a single step; if hysteresis is detected, the reading is reduced each time. If there is no lag and the read volume has not recovered to the initial value, then each increment... The maximum number of reads is In this embodiment, the normal read volume is set to 100, the minimum read volume is set to 10, the single adjustment step size is set to 20, and the upper limit of the read volume is 100.

[0169] The default wait mode trigger count is The safe mode trigger count is The safe mode query cycle is In this example, the values ​​are set to 5, 30, and 200ms respectively. If no new data is added, the count will be ≥ [value missing]. If no new data is found, it enters waiting mode and continues fast polling; if the count is greater than or equal to 1, it will enter waiting mode. If this happens, the system will enter safe mode and the query cycle will be changed from [previous time]. Adjusted to .

[0170] 4. Data deduplication, angle correction, and intermediate frame smoothing.

[0171] The acquired joint angle data is deduplicated, cached, and smoothed; in this embodiment, a HashSet is created. <int>Implement O(1) time complexity for deduplication of processed IDs by creating a Queue. <int>Maintain an LRU eviction queue (maximum capacity 5000), and create two lists as a data buffer pool (_bufferedData) and a target queue (_TargetData). Perform double validation on newly acquired data; add it to the buffer system after successful validation. Detect the joint angle difference between adjacent frames; if any axis angle difference changes abruptly, insert an intermediate frame using linear interpolation to generate smooth target data to be added to _TargetData. Figure 5 The diagram below illustrates the data processing and caching layer architecture and queuing process of this implementation case.

[0172] In this embodiment, the deduplication filtering condition of the ID deduplication check mechanism is as follows:

[0173]

[0174] In the above formula, let the first... The original joint data record is as follows ,in ;in This is a buffer for execution. This is the already processed set. Newly acquired data is validated. If the validated data ID is greater than the local last processed ID and the timestamp is greater than the local last processed time, the data is added to the cache system. When the eviction queue or buffer pool capacity exceeds the limit, the oldest data is removed; in this embodiment, the maximum capacity of the eviction queue is 5000, and the maximum capacity of the data buffer pool is 1500.

[0175] In this embodiment, the calculation method for buffer pool data angle correction is as follows:

[0176]

[0177] It can be represented by unfolding according to joint components as follows:

[0178]

[0179] In the above formula, This is the joint direction correction matrix. Install bias vectors for the model.

[0180] In this embodiment, the condition for determining the sudden change in the angle difference of any axis is:

[0181]

[0182] In the above formula, The threshold for the angle difference between any axes is set to 10° in this example.

[0183] In this embodiment, the intermediate frame is calculated as follows:

[0184]

[0185] 5. Construction of perturbation feature vectors and determination of interpolation mode

[0186] Create a sliding window of fixed size to statistically analyze system data intervals, frame times, and processing latency performance metrics in real time; also create a sliding window to statistically analyze average data intervals, average frame times, and average processing latency. Dynamically determine and switch motion modes based on perturbation feature vectors, and push performance metrics to the log layer for visualized monitoring. Figure 6 The diagram in the middle illustrates the feature vector construction and interpolation mode determination in this implementation case.

[0187] In the above process, the perturbation eigenvector is defined as:

[0188]

[0189] In the above formula, For the average data interval, To average the refresh interval, To average processing latency, This is a count value indicating that no new data has been obtained for a consecutive period of time.

[0190] ,

[0191] In the above formula, This is the length of the sliding window; in this embodiment, it is set to 20. When the input is high-frequency, the system automatically switches to JUMP mode, skipping interpolation and directly setting the target angle of the virtual model; otherwise, it maintains the normal interpolation mode.

[0192] 6. Easing interpolation drive

[0193] This embodiment implements virtual robotic arm joint motion drive based on the Unity engine. It batch processes target data and filters out expired data, inserting intermediate frames when the angle difference exceeds a preset threshold. After starting the motion coroutine, it executes either direct angle setting or EaseInOutQuad easing functions to achieve smooth interpolation based on the determined motion mode. The rotation axis parameters of the six joints are configured according to the robotic arm type. Configure the joint rotation axis parameters for different robotic arm types. (See attached document) Figure 7 The middle section is a schematic diagram of the easing interpolation driving method in this implementation case.

[0194] In the above process, the EaseInOutQuad easing function formula is:

[0195]

[0196] In the above formula, Indicates the interpolation progress coefficient; This represents normalized time.

[0197] 7. Asynchronous non-blocking log classification storage and batch writing

[0198] This embodiment employs an asynchronous, non-blocking mode for writing and managing system logs. System logs are divided into three categories: real-time driver logs, performance monitoring logs, and process status logs. These logs respectively record robotic arm joint angle data, system performance indicators, and assembly process execution status. Log information is added to a thread-safe log queue via a log-to-file interface. When the log queue accumulates 100 log entries or a timeout of 1000ms occurs, a background writing thread is started to batch-flush the logs to the file. If log writing fails, the logs are re-queued for retry. All logs are stored in JSON format, supporting subsequent parsing and visualization analysis. Figure 8 The diagram below illustrates the asynchronous non-blocking log classification storage and batch writing in this implementation case.

[0199] 8. Asynchronous monitoring of process instructions

[0200] An asynchronous monitoring method for process instructions is implemented, periodically querying three core data tables: the process flow table, the handling robot data table, and the assembly robot data table. It checks if the instruction trigger field in the data tables has a value, and if the current row ID is greater than the last processed ID, determines whether a new process instruction has been triggered. The instruction information is then called back to the main thread via the main thread scheduler to complete the process instruction issuance. After the instruction is executed, the instruction issuance field is cleared. Real-time monitoring of PLC and robot arm I / O signals, online status, and process execution progress enables full-dimensional real-time synchronization of the physical equipment and the virtual twin model's multi-device status. Figure 9 The middle section shows the multi-device status monitoring and process instruction cycle control flow of this implementation case.

[0201] 9. Motion segment detection and synchronous backtracking of master and slave robotic arms

[0202] A motion segment detection algorithm iterates through historical joint angle data by timestamp, determining motion segment breakpoints based on time differences exceeding a preset threshold and recording the start and end information of each motion segment. The start time of the main robotic arm's motion segments is stored as a global reference time. After reading the reference time from the robotic arm, the corresponding historical data for each time node is located using a synchronized data positioning and cleaning method, and the local cache is cleared. The master and slave robotic arms initiate historical data playback based on the same reference time, and synchronized motion is achieved using the motion-driven logic from step six. Figure 10 The diagram below illustrates the synchronous playback process of the master-slave robotic arms in the backtracking layer of this implementation case. (Attached) Figure 10 The diagram in the middle illustrates the synchronous playback process of the master-slave robotic arms in the backtracking driving layer of this implementation case.

[0203] In this embodiment, the time difference is calculated using the following formula:

[0204] In the above formula, The time difference between adjacent data. This is the current data timestamp. This is the timestamp of the previous data; in this example, A time interval greater than 10 seconds is considered a segmentation point in the motion.

[0205] 10. End-to-end thread safety mechanism

[0206] A full-chain thread safety mechanism is designed, encompassing data caching, log writing, and ID updates. This employs thread-safe queues, thread-safe dictionaries, and other thread-safe collections, and a main thread scheduler ensures that the 3D engine interface executes only on the main thread. A singleton database management system manages multiple database configurations, ensuring compatibility with heterogeneous industrial databases such as those for process management, assembly robotic arms, and handling robotic arms. An event callback interface is designed at the process control layer, making core parameters such as data read volume, cache capacity, calibration interval, and query cycle configurable and dynamically adjusted according to the industrial environment. Figure 11 The diagram below illustrates the end-to-end thread safety mechanism in this implementation case.

[0207] 11. Visual presentation and full-state synchronous display

[0208] This embodiment uses the Unity3D engine to visualize the motion data of the model-driven layer and the status data of the process control layer, realizing millisecond-level synchronous movement of the virtual robotic arm and physical equipment, real-time progress display of assembly processes, visual identification of equipment status (online / running / alarm), real-time chart display of performance monitoring indicators, online query of log data, playback of historical motion data and annotation of key nodes, and support for tracing the source of assembly failures.

[0209] Verification Example 1:

[0210] Figure 12 This chart shows the data transmission and processing efficiency statistics for this verification example, recording the data link performance from the PLC through the database to the client. The average data read volume per 0.1 seconds is 77.77 records, with 9 normal data reads and only 3 slightly below normal reads, resulting in a data read success rate of 75.0%. The average DataFrame read time is 22.34 ms, with 11 normal reads and only 1 slightly above normal read, resulting in a success rate of 91.7%. This verifies the database connection pool mechanism, exponential backoff retry strategy, and lag detection and dynamic read volume adjustment method in this invention, demonstrating stable, low-latency asynchronous data access capabilities under high-concurrency scenarios.

[0211] Figure 13 The system used in this verification example performs real-time statistics on the motion data of the assembly robot. The average read time for a normal UnityFrame is 10.18ms, with 11 normal reads and only 1 read with a slightly higher reading time, resulting in a read success rate of 91.7%. Simultaneously, for high-frequency operations such as the locking wire operation, the system automatically switches to JumpMode. Statistics show that the average normal JumpMode Rate is 47.707%, the average normal JumpMode Time is 2.971s, with 5 valid reads and a success rate of 80.0%. This verifies the effectiveness of the present invention's method of dynamically switching motion modes based on perturbation feature vectors and using the EaseInOutQuad easing function and intermediate frame adaptive algorithm to achieve smooth driving, ensuring smooth movement of the virtual robotic arm under millisecond-level synchronization.

[0212] Figure 14 This is the data management interface for this verification example. The system logs are divided into three categories: overall process logs, robot motion logs, and twin performance logs, corresponding to the classification and storage mechanism of "real-time drive logs, performance monitoring logs, and process status logs" in this invention. The interface lists multiple performance log records of the transport robot in detail. Each record includes an ID, recording time, number of records read in a single session, average data frame interval, average data frame time difference, and performance indicators such as "enable instantaneous movement." It also supports operations such as uploading and deleting logs. This interface verifies that this invention provides effective support for the visual analysis of system operation status and rapid problem localization by using a sliding window to statistically analyze the average data interval and frame time difference in real time and dynamically determining the motion mode based on the disturbance feature vector.

[0213] Figures 15(1)-(2) show the process execution time monitoring of this verification example. Statistical analysis was performed on the process duration of 50 time stages for the assembly robot and the transport robot. The full data shows that the median and average durations are close. The magnified view of the middle area further verifies that the execution time of most processes is concentrated in a very short range. The distribution of the total data volume in each stage below indicates that the data collection density is uniform. This verifies that the asynchronous non-blocking log classification and storage, asynchronous monitoring of process instructions, and data deduplication and smoothing mechanisms of this invention can accurately capture process execution time and identify anomalies, providing reliable data support for fault tracing in the assembly process.

[0214] Figures 16(1)-(2) show the backtracking control interface of this verification example, including the collaborative operation status of the transport robot backtracking controller and the assembly robot backtracking controller. Both support historical data playback by time point through the data retrieval function, and the drop-down list provides multiple time points for users to select. When the same time point is selected and playback is started, the system automatically loads the historical signal file at that moment. The transport robot side log displays the received task process and supports operations such as stop, backtracking speed adjustment, log management, task backtracking, view monitoring and status monitoring. At the same time, the "algorithm intelligent segmentation" function is provided, which can automatically segment historical motion data according to the motion segment detection algorithm, realize accurate synchronous playback and breakpoint resume of master and slave robotic arms based on the same reference time, and effectively verify the reliability of the present invention in historical data backtracking and multi-device collaborative playback.

[0215] Figures 17(1)-(3) show the actual operating status of this verification example on the experimental assembly workbench. The figures show the operating status monitoring interface of the digital twin system, which includes multiple visualization windows such as the view monitoring screen, the transport robot view, the virtual inspection view, and the real scene inspection. The monitoring log clearly records the complete assembly process from receiving the task execution request, sequentially switching the suction cup fixture, picking up the material, to releasing the workpiece, lowering the fixture, switching the gripper fixture, picking up the material, releasing and installing the material, and releasing the workpiece. The HMI panel provides real-time feedback on the online status, view monitoring, and visual inspection results, supports the acquisition of original photos and processed photos, and allows for immediate viewing of visual inspection feedback.

[0216] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / int> < / int>

Claims

1. A real-time driving method for digital twins of industrial robotic arms based on a hierarchical decoupling architecture, characterized in that, Includes the following steps: Step 1: Construct a layered and decoupled system architecture. The architecture includes functional layers for data acquisition and calibration, data processing and caching, performance monitoring, and model-driven functions, and realizes data interaction between layers through standardized interfaces. Step 2: Asynchronously monitor the database at fixed intervals to obtain the joint angle data of the robotic arm; determine the data synchronization status through hysteresis detection, and dynamically adjust the data reading amount for the next cycle based on the hysteresis amount; Step 3: Perform deduplication and verification on the acquired joint angle data, and detect and smooth abrupt changes in joint angles; Step 4: Create a sliding window to collect real-time statistics on the system's performance metrics and construct a disturbance feature vector based on the performance metrics; based on the disturbance feature vector, dynamically determine and switch the motion mode of the virtual robotic arm, the motion mode including at least the JUMP mode with directly set angle and the normal mode with easing function interpolation; Step 5: Based on the 3D engine, drive the virtual robotic arm and, according to the switched motion mode, perform direct angle setting or easing interpolation on the target joint angle data after the data processing and caching steps to control the joint movement of the virtual robotic arm.

2. The real-time driving method for digital twin of industrial robotic arm according to claim 1, characterized in that, In step 2, a database connection pool mechanism is used for asynchronous data access, and an exponential backoff retry strategy is configured for database operations.

3. The real-time driving method for digital twin of industrial robotic arm according to claim 1, characterized in that, In step 2, the method for adjusting the data read volume is as follows: calculate the latest record number in the database. With the latest record number processed locally The difference is used as a lag. , ; If the hysteresis Exceeding the dynamic threshold calculated based on the current read volume, i.e. If this occurs, it is identified as a lagging disturbance, and the planned read volume for the next cycle is reduced. for ; If no hysteresis disturbance occurs and the current read volume is less than the normal value, that is and At that time, increase the planned read volume for the next cycle. for In the formula, For dynamic threshold ratio, For the current read volume, This is normal read volume. Minimum read size, This is a single adjustment step size.

4. The real-time driving method for digital twin of industrial robotic arm according to claim 1, characterized in that, In step 3, the deduplication screening condition is: Let the first... The original joint data record is as follows ,in , ,in For the first The joint angle vector of each record. For the first The angle components of each joint in the frame, For the first One original joint data record, pending execution buffer. For the first The unique identifier of each record For the first The timestamp of the record The ID of the latest record processed in the system. The timestamp of the latest record processed in the system. For the processed set, a hash structure is used to maintain the eviction queue and data buffer pool.

5. The real-time driving method for digital twin of industrial robotic arm according to claim 1 or 4, characterized in that, In step 3, the joint direction correction matrix is ​​used. and model mounting bias vector Correct the joint angle data: The corrected angle data Add a buffer system; calculate the joint angle difference between adjacent frames in the buffer system, and when the angle difference exceeds a preset threshold, i.e. At that time, at least one intermediate frame is inserted by interpolation. In the formula, the subscript k,j represents the j-th joint of the k-th frame. This is the threshold for the angle difference.

6. The real-time driving method for digital twin of industrial robotic arm according to claim 1, characterized in that, The performance metrics include average data arrival interval. Compared to the average system rendering frame interval ;when If the input state is high frequency, switch to the JUMP mode; otherwise, maintain or switch to the normal mode.

7. The real-time driving method for digital twin of industrial robotic arm according to claim 1 or 6, characterized in that, In the normal mode, the EaseInOutQuad easing function is used to perform smooth interpolation calculations on the joint angles of the virtual robotic arm.

8. The real-time driving method for digital twin of industrial robotic arm according to claim 1, characterized in that, It also includes a historical data synchronization and playback step: motion segment detection is performed on the historical joint angle data. By detecting the time interval between adjacent data points, nodes with intervals exceeding a preset threshold are identified, thereby dividing the continuous motion data into multiple independent motion segments and recording the start and end information. In a multi-machine collaborative scenario, the start timestamp of a certain movement segment of the main robotic arm is set as the global reference time. This allows other slave robotic arms to automatically locate the same point in their own historical data after obtaining the reference time, and to synchronously start the playback of historical actions with the main robotic arm based on this unified time point. The playback process of the historical actions is achieved by using the 3D engine to drive the virtual robotic arm.

9. The real-time driving method for digital twin of industrial robotic arm according to claim 1 or 8, characterized in that, It also includes asynchronously monitoring process instructions and equipment status data at fixed intervals, and synchronously updating the process execution status and IO status steps of the virtual robotic arm; wherein, the core data table containing process instructions is queried, and when a new record is detected and the status field is marked as "unprocessed", a preset action sequence corresponding to the process instruction is triggered to execute, and the status of the record is updated to "processed".

10. The real-time driving method for digital twin of industrial robotic arm according to claim 1, characterized in that, The method employs a full-link thread safety mechanism, including using a thread-safe collection class to manage shared data caches in the data acquisition and calibration, data processing and caching steps. When recording system operation logs, asynchronous submission and writing of logs are achieved through a thread-safe queue; Furthermore, in the step of driving the virtual robotic arm based on the 3D engine, the main thread scheduler ensures that all calls to the 3D engine interface are executed on the main thread.

Images