Dual-channel control method and system for mobile dual-arm robot

Abstract

The application relates to the technical field of robot control, and discloses a double-channel control method and system for a mobile dual-arm robot, which comprises the following steps: running a first control program and a second control program in parallel in a physical memory; the second control program has a higher running frequency and has bottom-layer final control right; the first control program performs deduction based on sensor feedback, generates prediction data and prediction metadata containing a valid period timestamp; the second control program extracts the above data and external multi-source expected instructions, and performs timeliness verification by comparing absolute physical time of a system and the valid period timestamp; if the verification is valid, the multi-source expected instructions and the prediction data are subjected to amplitude limiting and synthesis processing to generate final control instructions; if the verification is invalid, the prediction data is blocked from participating in calculation, the chassis speed instruction is directly cleared to zero, and a position keeping instruction is issued to the mechanical arm. The application decouples environment deduction and bottom-layer execution, effectively avoids interference of expired data, and improves the safety fault tolerance capability of the robot.

Description

Technical Field

[0001] This invention relates to the field of robot control technology, specifically to a dual-channel control method and system for a mobile dual-arm robot. Background Technology

[0002] Mobile dual-arm robots combine the navigation capabilities of a mobile chassis with the operational capabilities of a multi-degree-of-freedom robotic arm, and their application in complex, unstructured environments such as warehousing and manufacturing is becoming increasingly widespread. Currently, the control systems of mobile robots mostly adopt a single architecture that couples environmental perception and inference with underlying motion drive. The control system typically acquires environmental sensor data, directly calculates the desired trajectory through an algorithm layer, and then sends it to the underlying actuators.

[0003] However, environmental perception and forward-looking simulation are computationally intensive tasks with typically long computation cycles that are susceptible to fluctuations in computation time due to environmental complexity. In a single architecture, such computational fluctuations or localized communication delays can lead to data blockage in the underlying high-frequency drive loops. While waiting for new simulation data, the underlying actuators may continue to execute outdated expected instructions from the previous cycle, potentially causing collisions in the absence of environmental safety warnings. Furthermore, when a mobile dual-arm robot encounters physical disturbances such as changes in ground friction or lag in motor servo response during actual operation, the measured physical state may deviate from the theoretically predicted trajectory. Existing control mechanisms struggle to perform amplitude-limiting arbitration between external task scheduling instructions and the underlying physical collision avoidance boundaries, and lack safety blocking and smooth degradation strategies for failed prediction data. This prevents timely safety intervention of the underlying hardware when the robot faces sudden environmental obstacles or system computational delays, posing safety risks of instruction conflicts and loss of control. Summary of the Invention

[0004] The technical problem solved by this invention is that existing mobile dual-arm robot control systems mostly adopt a single architecture that couples environmental simulation with underlying drive. In complex environments, when the perception computing power is blocked or the communication network is delayed, the underlying actuator is prone to receiving and executing outdated expected instructions, lacking a blocking protection mechanism for look-ahead prediction failure. Moreover, when encountering physical sideslip or following lag, it is difficult to implement safe arbitration and smooth degradation of multi-source instructions, resulting in safety hazards of instruction conflict and out-of-control collision.

[0005] To address the above problems, the present invention provides the following technical solution:

[0006] The first aspect of this invention provides a dual-channel control method for a mobile dual-arm robot, comprising:

[0007] The first control program and the second control program run in parallel in physical memory. The second control program runs at a higher frequency than the first control program, and the second control program has ultimate control over the underlying controller.

[0008] The first control program performs simulations based on sensor feedback, generating prediction data and prediction metadata containing a valid time stamp. The prediction data includes the upper limit data of chassis speed and the prediction data of robotic arm trajectory.

[0009] The second control program extracts prediction data, prediction metadata, and multi-source expectation instructions from external input.

[0010] The second control program obtains the current absolute physical time of the system and verifies the timeliness of the predicted data by comparing the absolute physical time with the validity period timestamp.

[0011] If the verification is valid, the second control program will perform amplitude limiting synthesis of the multi-source expected command and the predicted data to generate the final control command, which will be sent to the underlying controller to execute the action.

[0012] If the verification fails, the second control program blocks the predicted data from participating in the synthesis calculation of the control loop, directly overwrites and clears the currently circulating chassis linear velocity and chassis angular velocity commands, and sends the current position hold command to the left and right robotic arm controllers.

[0013] As one specific implementation method, the chassis speed upper limit data includes the linear velocity upper limit and the angular velocity upper limit. The first control program generates prediction data and prediction metadata containing a valid period timestamp, specifically including:

[0014] Extract point cloud ranging data from LiDAR, visual feature data from RGB camera, and depth image from depth camera. Use extended Kalman filter algorithm to perform spatiotemporal alignment and feature-level fusion of heterogeneous sensor data to output measured perception data.

[0015] Extract the minimum obstacle distance in front of the machine body, and calculate the upper limit of the linear velocity and upper limit of the angular velocity of the chassis based on the physical relationship that the minimum obstacle distance decreases monotonically.

[0016] Historical trajectory data and theoretically predicted trajectory data are extracted to calculate kinematic tracking residuals. The recursive least squares method is used to identify the actual wheel diameter parameters and equivalent wheelbase parameters online, and the model parameters of the robot kinematic model are dynamically updated.

[0017] Using the measured perception data as the initial state point, and combining the robot kinematics model with dynamically updated model parameters with the upper bound of linear velocity and upper bound of angular velocity, multi-step kinematic recursive calculation is performed to generate prediction data.

[0018] Assign a unified generation time timestamp to the forecast data, add the generation time timestamp to the product of the forecast validity period coefficient and the forward projection period, and write the validity period timestamp into the forecast metadata.

[0019] Furthermore, before obtaining the current absolute physical time of the system, a global clock synchronization step is also included: according to the IEEE1588 time synchronization protocol deployed in the system, the main control unit periodically broadcasts synchronization messages to the sensors and the underlying controller, and each hardware node performs clock deviation compensation and correction based on the measured network transmission delay to achieve global clock synchronization.

[0020] The second control program verifies the timeliness of the prediction data and also includes a second-level watchdog verification mechanism to monitor the activity of updates: by using a timer independent of the prediction channel, it records the time interval elapsed since the last successful reception and parsing of new prediction metadata; compares the time interval with the preset execution-side prediction timeout threshold; if the absolute physical time is greater than the validity period timestamp, or the time interval is greater than the preset execution-side prediction timeout threshold, it determines that the current prediction channel has entered the failure blocking mode.

[0021] Furthermore, the multi-source expected instructions and prediction data are combined using an arbitration limiting module, including:

[0022] For the linear motion control and steering motion control of the chassis, the absolute values ​​of the desired linear velocity and the desired angular velocity are compared with the corresponding upper limits of linear velocity and angular velocity, respectively. The smaller value is selected as the safety command amplitude, and the safety command amplitude is multiplied by the original direction sign to synthesize it.

[0023] For the motion control of the dual-arm manipulator, a closed-loop kinematic constraint equation for the end effector of the two arms is established in the dual-arm collaborative scenario with the grasping points of both hands as physical constraints. When the desired trajectory of the left arm and the desired trajectory of the right arm do not satisfy the closed-loop kinematic constraint equation for the end effector of the two arms in terms of spatial pose, the internal force coupling residual of the two arms is calculated by the Jacobian matrix, and the desired joint angle is synchronously adjusted according to the preset impedance control admittance model to resolve the torque conflict.

[0024] The system verifies cycle by cycle whether the expected joint angle after conflict resolution falls within the legal envelope range formed by the robot arm trajectory prediction data. If an attempt is made to break through the boundary of the legal envelope range, the expected joint angle that exceeds the limit is forcibly truncated to the critical edge position of the prediction envelope. Combining the factory-set joint velocity limit parameters and the joint acceleration physical limit threshold, a smooth curve interpolation calculation is performed between the current actual joint position and the truncated target critical position.

[0025] Furthermore, after the second control procedure extracts the prediction metadata, it also includes:

[0026] The timestamp and inference sequence number carried by the prediction metadata are checked. When the timestamp interval between two adjacent frames of prediction metadata is within a reasonable range and the inference sequence number remains monotonically increasing, the counter reflecting the continuous reception status is incremented. If the value of the counter does not reach the preset threshold for the number of consecutive received frames, the look-ahead ready gating protection mechanism is triggered, and a rigid speed amplitude constraint is applied to the linear speed command involving chassis motion, limiting the linear speed command involving chassis motion to the preset gating safety speed limit.

[0027] Furthermore, during the parallel operation of the first and second control programs, the deviation monitoring module also performs real-time monitoring of state deviations and dynamic switching of four modes, including:

[0028] The difference between the measured physical parameters at the current moment and the expected predicted parameters in the predicted data under the same reference coordinate system is calculated to obtain the state deviation. The state deviation is a multi-dimensional vector array that includes the spatial Euclidean distance deviation of the chassis coordinates and the angle deviation of each robotic arm joint. The state deviation is compared with the preset first deviation threshold, second deviation threshold and third deviation threshold by condition judgment branch. The first deviation threshold, second deviation threshold and third deviation threshold increase step by step from low to high. If the state deviation is less than or equal to the first deviation threshold and the timeliness verification is valid, the system maintains or switches to the normal look-ahead assist mode, and the underlying control loop operates normally according to the final control command.

[0029] Furthermore, the real-time monitoring of execution state deviations and dynamic switching of four modes also include:

[0030] If the state deviation diverges and meets the condition of being greater than the first deviation threshold and less than or equal to the second deviation threshold, the system will be downgraded to a speed-limiting downgrade mode, and the current chassis linear velocity and angular velocity commands will be uniformly multiplied by a preset attenuation coefficient. If the state deviation further deteriorates and meets the condition of being greater than the second deviation threshold and less than or equal to the third deviation threshold, the system will be downgraded to a pure feedback control mode, and the data flow input of the first control program will be actively cut off. The underlying controller will degenerate into an isolated closed-loop state that relies on measured data for close-range anti-collision feedback.

[0031] Furthermore, if the state deviation exceeds the ultimate physical boundary and is greater than the third deviation threshold, or if a hardware emergency power-off signal is received from a manual operator, a global emergency stop and underlying hardware protection are implemented through the emergency stop module, including:

[0032] Actively block the data output link, intercepting all flowing regular expected commands and prediction sequences; forcibly set the values ​​of linear velocity and angular velocity commands sent to the chassis to zero; send safety holding trajectory or zero return trajectory to the left arm controller and right arm controller, wherein sending the safety holding trajectory includes extracting the current measured joint angle of each joint of the robotic arm and equivalently assigning the target joint angle command of the next cycle to the measured joint angle; send a state lock command to the dual gripper controller to maintain the current current closed loop and gripping torque.

[0033] Furthermore, before the underlying controller executes the action, it also includes control logic activated in a stepped timing manner:

[0034] The controller management module instantiates a controller state mapping table in system memory. The controller state mapping table is used to record the current running status word of the underlying controller. The activation tasks of the underlying hardware are arranged according to a preset tiered time sequence. When the target time node is reached, the current running status word of the corresponding controller is queried. If the current running status word indicates that it has not been activated, an activation command message is sent and a confirmation heartbeat signal is waited for within the tolerance time window. If a confirmation heartbeat signal is captured, the status word is updated to activated and ready. If the tolerance time window is exceeded, a cyclic retry mechanism based on a preset maximum number of retries is triggered.

[0035] A second aspect of the present invention provides a dual-channel control system for a mobile dual-arm robot, used to implement the dual-channel control method for a mobile dual-arm robot according to any of the above embodiments, comprising:

[0036] The first control program is used to perform inference based on sensor feedback, generate prediction data and prediction metadata containing a valid time stamp. The prediction data includes chassis speed upper limit data and robotic arm trajectory prediction data.

[0037] The second control program runs in parallel with the first control program in physical memory. The second control program runs at a higher frequency than the first control program, and the second control program has ultimate control over the underlying controller.

[0038] The second control program is configured to: extract prediction data, prediction metadata, and multi-source expected commands from external input; obtain the current absolute physical time of the system, and verify the timeliness of the prediction data by comparing the absolute physical time with the valid expiration time stamp; if the verification is valid, perform amplitude-limited synthesis processing on the multi-source expected commands and prediction data to generate the final control command, and send it to the underlying controller to execute the action; if the verification fails, block the prediction data from participating in the synthesis calculation of the control loop, directly overwrite and clear the currently flowing chassis linear velocity and chassis angular velocity commands, and issue the current position holding command to the left and right robotic arm controllers.

[0039] This invention provides a dual-channel control method and system for a mobile dual-arm robot. It offers the following advantages:

[0040] 1. This invention constructs a dual-channel control architecture in which the first control program and the second control program run in parallel, decoupling the environmental inference calculation from the underlying hardware execution in terms of operating frequency and memory space. This design enables the underlying drive to maintain a high frequency refresh by the second control program, which has the final control, when the system is performing high-computation-consuming perception and prediction. This avoids the problem of underlying control lag caused by inference algorithm blocking or computing power fluctuations, and ensures the continuity of the robot control loop and the stability of the system.

[0041] 2. This invention adopts a limiting synthesis and envelope constraint mechanism based on predicted data. After the second control program obtains the expected external multi-source instructions, it will compare and truncate the instructions with the chassis speed upper limit and the robot arm trajectory prediction data output by the look-ahead simulation. This mechanism ensures that the drive instructions finally sent to the bottom actuator are always limited within the dynamic safety boundary of the environment, effectively solving the logical conflict between the external operation scheduling instructions and the bottom collision avoidance requirements, and preventing the robot from performing physical over-limit actions in complex environments.

[0042] 3. This invention establishes a timeliness verification and multi-dimensional state deviation monitoring mechanism based on dual watchdog timers. By comparing the absolute physical time with the validity period of the predicted metadata, and performing multi-level threshold judgment when there is a deviation between the measured state and the predicted state, the control system can actively block expired data from participating in the calculation when the predicted data network lag, channel update timeout, or underlying physical tracking error divergence is detected. This triggers the chassis to zero-speed parking or gradually degrades to speed limit downgrade and pure feedback control mode, eliminating the safety hazard of the robot relying on failed data for operation and improving the system's fault tolerance protection capability in unstructured environments. Attached Figure Description

[0043] Figure 1 This is a diagram showing the overall physical system composition of the present invention;

[0044] Figure 2 This is a diagram of the dual-channel control architecture of the present invention;

[0045] Figure 3 This is a data flow diagram for the execution and arbitration of the present invention;

[0046] Figure 4 This is a flowchart illustrating the simulation-to-real-machine switching process of the present invention.

[0047] Figure 5 This is a diagram showing the relationship between the laser sector and the upper velocity bound of the present invention.

[0048] Figure 6 This is a forward-looking timeline diagram for the present invention;

[0049] Figure 7 This is a state machine diagram for deviation monitoring in this invention;

[0050] Figure 8 This is a comparison chart of the experimental indicators of the present invention.

[0051] Among them, 10 is the first control program; 20 is the second control program; 30 is the interface contract loading module; 40 is the arbitration limiting module; 50 is the deviation monitoring module; 60 is the emergency stop module; 70 is the controller management module; 80 is the sensor feedback; and 90 is the host computer human-machine interaction module. Detailed Implementation

[0052] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] See attached document Figure 1 ,like Figure 1 As shown, the overall physical system includes a head pan / tilt with cameras, a mobile base with differential drive and passive wheels, a sensing unit with Lidar / RGB / Depth sensors, a left arm and a right arm with 5DOF grippers, and an industrial PC. The system runs on the ROS2 Jazzy operating system and includes a first control program and a second control program. Based on the above, the physical hardware of the mobile dual-arm robot includes a mobile chassis, two robotic arms, and two grippers. The system is equipped with an independent low-level controller that interfaces with each hardware physical unit.

[0054] See attached document Figure 2 This invention provides a dual-channel control system for a mobile dual-arm robot, which may include a first control program 10 and a second control program 20. For example... Figure 2 As shown in the dual-channel control architecture, sensor feedback provides the status of the LiDAR, Odom, and Joint; the system communicates via an Interface Contract (YAML+Hub). The first control program 10 ( Predict, such as ) in a periodic Steps Perform forward-looking simulations and publish data via / predict / * related topics; Second control procedure 20 ( Execute, such as ) in a periodic It runs and can optionally connect to a host computer (GUI optional). The underlying layer interfaces with 6 controllers via ros2_control, including differential drive, arms, and grippers, receiving chassis speed commands. With joint trajectory commands, the overall system supports Gazebo simulation or real hardware (Gazebo or Real HW) deployment.

[0055] The first control program 10 and the second control program 20 run in parallel. The first control program 10 and the second control program 20 maintain independent execution processes, with no call stack coupling between them. The second control program 20 has ultimate control over all the underlying controllers of the system.

[0056] The first control program 10 and the second control program 20 are connected via an interface contract loading module 30 and a status acquisition module.

[0057] The interface contract loading module 30 reads the unified settings file and writes the actuator interface, sensor interface, and system operating mode into the parameter service.

[0058] The status acquisition module collects joint status, mileage information, and laser ranging data.

[0059] The first control program 10 includes a forward-looking simulation module and a prediction release module.

[0060] The forward-looking inference module calculates the state boundary based on the kinematic model of the mobile dual-arm robot and environmental constraints, and recursively generates a prediction sequence.

[0061] The prediction and release module publishes chassis speed upper limit data, robotic arm trajectory prediction data, and prediction metadata with simulation sequence number and validity period to the external communication channel.

[0062] The second control program 20 includes a look-ahead ready gating module, an arbitration limiting module 40, a deviation monitoring module 50, an emergency stop module 60, and an instruction issuing module.

[0063] The look-ahead ready gating module restricts the output of chassis non-zero speed commands until the predictive metadata remains valid.

[0064] Arbitration limiting module 40 receives the desired speed and desired trajectory, and performs limiting synthesis processing on the desired command and the chassis speed upper limit and robot arm trajectory envelope given by the first control program 10.

[0065] The deviation monitoring module 50 compares the measured state acquired by the state acquisition module with the predicted state generated by the look-ahead simulation module, outputs the state deviation, and switches between multi-level control modes in combination with the validity of the predicted data.

[0066] When the extreme deviation condition is triggered, the emergency stop module 60 takes over the system circuit, resets the chassis speed to zero, and sends a safety holding trajectory or a zero return trajectory to the dual robotic arms and dual grippers.

[0067] The command issuing module issues the final chassis speed command and joint trajectory command with timestamps to the underlying controller.

[0068] The system includes a hardware abstraction layer for the docking controller management module 70. The controller management module 70 manages six hardware controllers. The six hardware controllers include a joint status broadcaster, a differential chassis controller, a left arm controller, a right arm controller, and a dual gripper controller.

[0069] See attached document Figure 3 The present invention provides a dual-channel control method for a mobile dual-arm robot, which may include:

[0070] Combination Figure 3 The data flow indicates that the human-computer interaction interface or navigation (GUI / Nav) sends the desired speed and desired joint angle. , The first control program performs forward-looking simulations. The predictor outputs the upper bound of the velocity and the predicted joint angles and trajectory envelope. The aforementioned commands, along with feedback from sensors including the odometer and joints, are input to the Arbitrate M5 module 40 to perform minimum limiting and envelope constraints. After a 200ms watchdog timer check, the Publish M6 module sends the timestamped chassis speed command message (Twist Stamped) and joint trajectory command message (Joint Trajectory) to the 6-channel controller (6 ctrl). The specific execution steps of this method are as follows:

[0071] S1. The system powers on and starts up, and calls the interface contract loading module 30 to complete the loading of system parameter settings. The controller management module 70 activates the six underlying hardware controllers in sequence according to the preset time sequence.

[0072] S2. The first control program 10 and the second control program 20 enter the parallel operation stage, and the status acquisition module continuously acquires the robot's actual perception data.

[0073] S3, the forward-looking simulation module calculates the dynamic boundary of the environment based on laser ranging data, and generates the upper limits of linear velocity and angular velocity to constrain the chassis operation.

[0074] S4. The forward-looking deduction module combines the robot's kinematic model to perform multi-step kinematic recursive calculations, generating chassis pose prediction data and robotic arm trajectory prediction data.

[0075] S5. The prediction and release module releases the upper limit of chassis speed and the prediction data of robotic arm trajectory to the network environment, and simultaneously releases prediction metadata including the simulation sequence number and the effective period timestamp.

[0076] S6. The second control program 20 reads the latest prediction data and the underlying measured feedback status at a higher operating frequency than the first control program 10.

[0077] S7. The forward-looking ready gating module checks the timeliness status of the forecast metadata and restricts the chassis control commands to a low-speed safety threshold range during the forecast not-ready stage.

[0078] S8, the arbitration limiting module 40 receives external input commands and performs component-by-component numerical fusion of the external input commands with the chassis speed upper limit and the robotic arm trajectory envelope generated by the first channel.

[0079] S9. The second control program 20 monitors the timestamp verification results and channel update frequency of the prediction metadata. When it is determined that the prediction data is invalid, it blocks the prediction data from participating in the control loop and executes the chassis zero-speed protection action.

[0080] S10, Deviation monitoring module 50 calculates the system deviation between the predicted state and the measured state, and triggers normal look-ahead assist mode, speed limit degrading mode or pure feedback control mode according to the magnitude of the deviation.

[0081] S11, Emergency Stop Module 60 forcibly intervenes in the control process when the system state deviation exceeds the limit safety threshold, and issues hard braking and equipment return commands to the execution layer.

[0082] S12, the instruction issuing module collects the final control instructions after security verification, adds a timestamp, and uniformly dispatches them to the six hardware controllers to execute physical actions.

[0083] See attached document Figure 4 ,like Figure 4 As shown, the system first determines whether to use simulation mode. If it is (Y), then it is true (true: Gazebo), the system starts the Gazebo simulation, performs clock bridging, and uses the simulation time. If not (N), then it is false (Real HW), and the system uses real hardware and calls the corresponding vendor plugin. Both use the same YAML interface contract (same contract / SameYAML contract), ensuring that the logic of the first control program and the second control program remains unchanged. (logicunchanged). Based on this mechanism, the interface contract loading module 30 provided by the present invention is set in the initialization stage of the control system to establish a unified underlying communication address mapping rule and system operation parameter system for the first control program 10 and the second control program 20.

[0084] The first control program 10 and the second control program 20 maintain independent running spaces in physical memory. To ensure that the two parallel programs maintain absolutely consistent communication semantics during asynchronous interaction, the interface contract loading module 30 performs parameter loading operations based on a shared configuration file. The specific implementation logic of interface contract loading is as follows:

[0085] In this embodiment, the interface contract loading module 30 reads the system's pre-stored unified settings file and extracts the system's current operating mode status word. The operating mode status word indicates whether the system is currently in simulation test mode or physical deployment mode. The interface contract loading module 30 writes the operating mode status word into the system's global parameter service, which is used by the first control program 10 and the second control program 20 as the basis for conditional branch judgment when instantiating the hardware communication interface.

[0086] Based on the extracted operating mode, the interface contract loading module 30 further parses the peripheral node topology mapping relationship in the unified settings file to generate an actuator interface set and a sensor interface set. The actuator interface set contains the communication channel addresses and data structure definitions for the system's underlying control unit to receive control commands; the sensor interface set contains the communication channel addresses and data structure definitions for feedback data published by various environmental and body perception sensors.

[0087] For the chassis motion control unit of the mobile dual-arm robot, the interface contract loading module 30 sets up a chassis speed command channel and a chassis mileage information channel. The chassis speed command channel specifies the specific communication topic for the differential chassis controller to receive drive speed commands with timestamps. Correspondingly, the chassis mileage information channel specifies the specific communication topic for the differential chassis controller to publish the measured machine pose and measured chassis running speed to the upper-level computing unit.

[0088] For the environmental perception unit, the interface contract loading module 30 sets up a laser ranging data channel. This laser ranging data channel is bound to the communication topic for publishing raw point cloud data from the lidar hardware. To ensure the consistency of the spatial calculation baseline, the interface contract loading module 30 writes a reference coordinate system identifier representing the lidar installation location into the global parameter service, enabling the look-ahead simulation module to call the correct spatial coordinate transformation tree for calculation.

[0089] For the dual-arm manipulator, the interface contract loading module 30 sets up a robotic arm trajectory control channel and a dual-gripper control channel. The interface contract loading module 30 registers arrays of multi-degree-of-freedom joint names for the left and right arms respectively in the global parameter service, and binds the communication topics for the left and right arm controllers to receive the joint trajectory point sets. This step simultaneously completes the address mapping operation for the dual-gripper controller instruction receiving topic.

[0090] To standardize the system's timing flow, the interface contract loading module 30 writes the basic algorithm constraint parameters required for the control system's operation into the global parameter service. These basic algorithm constraint parameters include the look-ahead estimation period. Kinematic recursive step count Predicted execution-side channel timeout threshold And the calculation coefficient for the predicted effective period The aforementioned parameters are typically determined through a comprehensive calibration based on the inherent control cycle of the underlying hardware and the physical inertial response characteristics of the robot itself. As a preferred implementation, in the setting of the control system's operating parameters, the look-ahead calculation cycle... Set to 50ms, kinematic recursion steps Set to 10 steps, predict the execution side channel timeout threshold. The calculation coefficient for the predicted effective period is set to 200ms. It is set to 2.0.

[0091] By executing the above-described setup and loading steps, the interface contract loading module 30 deploys the unified communication mapping rules. The first control program 10 and the second control program 20 send and receive data according to the communication channel addresses recorded in the actuator interface set and sensor interface set, effectively reducing the probability of communication address conflicts or data format misalignments during parallel operation. Regarding the specific character parsing algorithm for the unified setting file and the underlying data storage mechanism for the global parameter service, those skilled in the art can use existing data serialization parsing libraries and inter-process communication storage frameworks. The underlying implementation logic is well-known in the field and will not be elaborated upon here.

[0092] After loading the aforementioned interface contracts and basic parameters, the system also needs to perform an orderly wake-up of the underlying hardware controllers to ensure a smooth startup of the physical execution layer. To prevent multiple concurrently running underlying hardware controllers from simultaneously vying for communication bus bandwidth and causing bus congestion at the moment of system power-up, the controller management module 70 within the control system is equipped with a tiered activation control mechanism for the underlying hardware.

[0093] After the system starts up, the controller management module 70 initiates a controller activation task through the underlying hardware abstraction layer. The controller management module 70 internally maintains an activation status table that records the list of controlled nodes in the system.

[0094] The controller management module 70 sends wake-up commands to the six hardware controllers sequentially according to a preset tiered time sequence. The tiered time sequence has multiple trigger time nodes. As a specific setting in this embodiment, the set trigger time nodes are the 10s, 14s, 17s, 20s, 23s, and 26s after the system is powered on.

[0095] When a specific trigger time node is reached, the controller management module 70 activates the specific underlying hardware controller bound to the current time node. The six trigger time nodes, according to the set order, respectively wake up the joint status broadcaster, differential chassis controller, left arm controller, right arm controller, and dual gripper controller.

[0096] Before executing the wake-up commands for each hardware node, the controller management module 70 queries the activation status table in real time to verify the current feedback status of the target controller. For hardware controllers that have already reported being in an active running state, the controller management module 70 skips the step of repeatedly sending wake-up commands and waits for the next trigger time node to execute the corresponding hardware wake-up operation. The above-mentioned verification mechanism of skipping repeated loading further reduces the communication overhead of the control system initialization phase. In addition, if a specific controller fails to report a successful activation status within the corresponding trigger time node and its tolerance window, the controller management module 70 will trigger a hardware initialization anomaly alarm and perform a limited number of retries to prevent the system from falling into a logical dead zone of infinite waiting due to the failure of a single node.

[0097] The controller management module 70 provided by this invention serves as a bridge between the system software core and the underlying physical hardware, and is responsible for connecting to the hardware abstraction layer and performing overall scheduling and status maintenance of the six hardware controllers.

[0098] In multi-degree-of-freedom robot systems, multiple heterogeneous communication buses often exist at the bottom layer. The controller management module 70 establishes a communication connection with the physical hardware through the hardware abstraction layer, thereby shielding the differences in the underlying bus protocols. For the encapsulation of the underlying bus communication protocol and the message transmission and reception mechanism of the hardware abstraction layer, those skilled in the art can use existing open-source industrial control communication protocol stacks for configuration and implementation. The underlying driver implementation is well-known technology in this field and will not be elaborated upon here.

[0099] From a hardware operating principle perspective, if multiple underlying hardware servo drivers simultaneously initialize and send handshake messages to the upper layer at the moment the robot is powered on, it is highly susceptible to limitations imposed by the inherent bandwidth limit of the industrial bus, potentially leading to bus arbitration conflicts and transient peak current surges. Therefore, in this embodiment, the controller management module 70 incorporates a tiered timing activation strategy. This strategy achieves safe and stable loading of hardware resources through step-by-step timing allocation and status verification mechanisms.

[0100] The control logic for this step-by-step timing activation is as follows:

[0101] After the system is powered on and the interface contract loading module 30 completes the basic parameter settings, the controller management module 70 instantiates a controller state mapping table in the system memory. This mapping table is used to record the current operating status words of the six hardware controllers. The six hardware controllers involved in the system specifically correspond to the joint status broadcaster, differential chassis controller, left arm controller, right arm controller, and dual gripper controller.

[0102] The controller management module 70 arranges the activation tasks of the underlying hardware according to a preset tiered time sequence. In this embodiment, the set of activation time nodes is set as follows: As a preferred parameter setting, to The specific values ​​correspond to the 10s, 14s, 17s, 20s, 23s, and 26s after system startup, respectively. The above time intervals are set based on the self-test time of the underlying firmware of each controlled node and the maximum throughput bandwidth of the communication bus, in order to effectively reduce the probability of data packet loss and network congestion at startup.

[0103] The control system internally maintains a full-time counter that starts counting from power-on. When the full-time counter reaches any target time point... When, the index variable The controller management module 70 locates the current target time node. The first bound The hardware controller for the road. The six target time nodes, in ascending order, sequentially wake up the joint status broadcaster, differential chassis controller, left arm controller, right arm controller, and dual gripper controller.

[0104] Before actually issuing the wake-up command via the communication bus, the controller management module 70 performs a pre-check of the hardware activation status. The controller management module 70 queries the controller status mapping table for the corresponding... The current running status word of the hardware controller. If the current running status word indicates that the controller is already in an activated and ready state, the controller management module 70 actively skips the repeated loading process for that controller and does not send any wake-up messages, but directly enters the waiting loop for the next target time node. By introducing this status word verification and judgment mechanism, the system can effectively reduce redundant wake-up data packet sending actions in scenarios such as software restart or hot-plugging of some nodes.

[0105] If the current running status word indicates that the controller has not yet been activated, the controller management module 70 sends a message to the first controller through the hardware abstraction layer. The hardware controller sends an activation command message containing initialization settings parameters. After sending, the controller management module 70 opens a tolerance time window that matches the characteristics of the controller, within which it waits for the underlying hardware to provide a heartbeat signal confirming the operating status. Typically, the duration of this tolerance time window is calculated based on the rated time for the target controller firmware startup plus the maximum network latency for round-trip communication.

[0106] Once the hardware abstraction layer successfully captures the acknowledgment heartbeat signal returned by the underlying hardware within the tolerance time window, the controller management module 70 updates the status word of the corresponding node in the controller status mapping table to "activated and ready." Furthermore, if no acknowledgment heartbeat signal is received after the tolerance time window expires, the controller management module 70 does not directly block the system, but instead triggers a retry based on a preset maximum number of times. The loop retry mechanism. As a specific implementation, the maximum number of retries... It can be set to 3 times. If it passes After the second retry, the target node remained offline. Only then did the controller management module 70 officially record the hardware node loading anomaly and trigger a system-level initialization failure alarm. This anomaly reporting mechanism enables the second control program 20 to promptly intercept subsequent high-level logic operations and instruction issuance when there is a missing physical execution layer, protecting the system from the risk of unexpected actions caused by underlying disconnection.

[0107] The first control program 10 provided by this invention serves as the system's look-ahead simulation channel, primarily responsible for continuously monitoring environmental changes and calculating dynamic motion boundaries that comply with safety constraints during robot operation. This part of the logic operation does not directly participate in the high-frequency real-time driving of the underlying hardware, but rather provides safety constraint benchmarks for subsequent instruction arbitration.

[0108] The state acquisition module and the look-ahead simulation module deployed within the first control program 10 operate collaboratively according to a set timing sequence. The specific logic for state synchronization and dynamic boundary calculation of the environment is as follows:

[0109] In this embodiment, the status acquisition module uses a fixed calculation period. Perform synchronous acquisition of multi-source sensing data. As a preferred setting, the calculation cycle is... The time period is set to 50ms. This time period takes into account the physical inertia of the mobile chassis, the normal response time requirements for environmental changes, and the computing power load of the onboard computing unit, aiming to achieve a balance between environmental feature capture and system operating resources. The state acquisition module extracts perception data (i.e., sensor feedback 80) from each sensor communication node, specifically covering the position and velocity status of each robotic arm joint from the underlying feedback, the differential chassis pose information calculated by the chassis odometer, and the environmental point cloud ranging data output by the LiDAR. To improve the confidence and robustness of environmental perception, the state acquisition module incorporates a multi-sensor fusion algorithm. The state acquisition module extracts the point cloud ranging data from the LiDAR, the visual feature data from the RGB camera, and the depth image from the depth camera. It then uses an extended Kalman filter algorithm to perform spatiotemporal alignment and feature-level fusion of the above heterogeneous sensor data, outputting a fused global 3D environmental grid map and high-precision pose observations, which serve as the basic data input for subsequent look-ahead simulations.

[0110] See attached document Figure 5 ,like Figure 5 As shown, when a LiDAR (Light Detection and Ranging) system detects an obstacle in front of it, it captures the area directly in front. A scan sector of (+ / -30deg) is defined, and the minimum obstacle distance is extracted from it. Finally, the calculation is based on the formula for the upper limit of velocity. The upper limit of safety constraints is determined. After acquiring the aforementioned perception data, the look-ahead simulation module extracts effective obstacle features in front of the robot body based on the lidar ranging data. Considering that the main collision risk of the mobile robot is concentrated on the direction vector of its forward motion trajectory, the look-ahead simulation module extracts a preset azimuth angle directly in front from the original omnidirectional radar point cloud. Scanned sector data within the specified range. As a specific implementation setting, the preset azimuth angle of this sector... The range is defined as [-30°, 30°]. Within this target scanning sector, the look-ahead module traverses all valid ranging points, calculates and extracts the minimum obstacle distance closest to the origin of the robot's body coordinate system. To avoid data anomalies or computational deadlocks caused by a completely empty field of view in front of the robot, if no valid obstacle reflection points are detected within the target scanning sector, the look-ahead inference module will adjust the minimum obstacle distance. The value is forcibly assigned to the preset maximum effective range of the radar. For the denoising and filtering of the raw lidar data and the mapping and transformation of the underlying spatial coordinate system, those skilled in the art can use existing point cloud processing algorithm libraries. The underlying processing logic is well-known in the field and will not be elaborated upon here.

[0111] The forward-looking simulation module utilizes the extracted minimum obstacle distance The dynamic boundary used to guide the safe operation of the chassis is calculated. This dynamic boundary is specifically represented by the upper limit of the linear velocity of the chassis operation. upper limit of angular velocity To ensure obstacle avoidance safety while maintaining the robot's operational continuity, the upper bound of the linear velocity is... upper limit of angular velocity The calculation logic follows the minimum obstacle distance. The physical relationship is monotonically decreasing, and it is superimposed with an amplitude cutoff protection mechanism based on the mechanical limits of the chassis hardware.

[0112] From the perspective of kinematic control principles, the control system needs to trigger smooth deceleration when an obstacle enters a specific danger zone and reduce the speed to zero before reaching an absolutely safe distance. Based on this, the upper limit of linear velocity... The calculation uses the minimum obstacle distance. The mapping method involves multiplying by a positive gain coefficient and adding a negative safety bias term. This mapping result is further limited to the maximum speed range allowed by the underlying hardware through numerical truncation. As the specific operational logic of the control program in this embodiment, the upper bound of the linear velocity... The calculation formula is:

[0113] ;

[0114] in, The function represents the internal independent variable Forced restrictions Numerical truncation within a closed interval; This is the upper bound of the linear velocity; The minimum obstacle distance is 0.35; the linear velocity forward gain is 0.35; the safety bias term is -0.05, the absolute value of which represents the reserved zero-speed braking safety distance boundary; the constant 0.6 represents the maximum linear velocity limit of 0.6 m / s.

[0115] Similarly, for chassis steering actions, the upper limit of angular velocity... A similar mapping truncation logic is employed. As a specific setting in this embodiment, the upper bound of angular velocity is... The calculation formula is:

[0116] ;

[0117] in, The function represents the internal independent variable Forced restrictions Numerical truncation within a closed interval; This is the upper limit of angular velocity; The minimum obstacle distance; constant 0.8 is the forward gain of angular velocity; constant -0.15 is the steering safety bias term; constant 2.0 represents the maximum angular velocity limit of 2.0 rad / s.

[0118] By employing the dynamic boundary calculation method of linear mapping superimposed with threshold truncation, the look-ahead simulation module can smoothly and monotonically reduce the upper limit of the chassis's motion capability as environmental obstacles gradually approach the robot. This mechanism provides a theoretically safe data benchmark for subsequent multi-step kinematic recursive calculations and dual-channel command arbitration.

[0119] See attached document Figure 6 ,like Figure 6 The simulation time (ms) axis is shown, representing the first control program in each simulation cycle. Publish predictive metadata topics ( publish / predict / meta each ), including the sequence number of each look-ahead recursion step (e.g. ) and the set validity period ( The second control procedure only receives the latest derivation sequence number if the current time is less than the validity period. Only accepts latest if Under this timing mechanism, the look-ahead prediction module provided by this invention, after acquiring measured perception data and dynamic environmental boundaries, further combines the physical model of the robot body to perform multi-step kinematic recursive calculations to generate a continuous prediction sequence of the future motion state of the mobile dual-arm robot. This prediction sequence essentially constitutes the robot's safe motion envelope over a period of time in the future.

[0120] The look-ahead module uses the robot's current state as the starting point for recursion and iteratively predicts future pose changes through discretized time steps. The specific execution logic for kinematic recursion and prediction sequence generation is as follows:

[0121] In this embodiment, the look-ahead simulation module performs a recursive initialization operation. The look-ahead simulation module extracts the measured chassis pose, chassis speed, and position and velocity parameters of each joint of the dual robotic arms from the state acquisition module at the current moment, defining these parameters as the initial state points for kinematic recursion. To match the system's high-frequency control requirements while considering computational overhead, the look-ahead simulation module sets the time step size for each recursion to... Set as a forward-looking projection cycle Equal, that is As a preferred setting, the system sets the number of look-ahead recursion steps. The timeframe is 10 steps. This means that the forward-looking simulation module will calculate the system state change trajectory within 500ms based on the current state. The above simulation duration window is typically set to fully cover the total system delay time from the underlying hardware receiving instructions and parsing messages to the motor overcoming mechanical inertia to generate actual displacement.

[0122] For the chassis motion unit, the look-ahead simulation module establishes a discretized differential kinematic recursive model based on the underlying physical characteristics of the differential chassis controller. Considering that kinematic model parameters may experience physical drift due to mechanical wear or load changes, the look-ahead simulation module is equipped with an online model parameter calibration mechanism. The module extracts historical trajectory data from the measured chassis odometer feedback and the corresponding theoretical predicted trajectory data, calculates the kinematic tracking residual, and uses recursive least squares to identify the actual wheel diameter parameters and equivalent wheelbase parameters of the chassis online, dynamically updating the model parameters of the differential kinematic recursive model. During the recursion process, the look-ahead simulation module uses the assumption of maintaining a constant speed while keeping the current measured control speed constant as the prediction drive source. To ensure the safety of the simulated trajectory, within each recursive time step, the expected input speed of the chassis is limited by the dynamic boundary calculated in the previous execution step. Specifically, the absolute values ​​of the expected chassis linear velocity and expected chassis angular velocity during the recursion process are strictly limited to the corresponding upper bounds of linear velocity and angular velocity. Under the premise of meeting the above safety constraints, the forward-looking simulation module calculates the predicted spatial pose of the chassis for the next time step by discretizing and integrating the expected linear velocity and expected angular velocity after the constraint according to the recursive time step based on the current chassis pose.

[0123] For the dual-arm manipulator, the look-ahead simulation module performs recursive trajectory calculations for each independent joint of the robotic arm. Considering the physical limitation of the maximum motor speed during actual operation, the expected joint speeds are truncated before integration. The look-ahead simulation module iterates through the multi-degree-of-freedom joints controlled by the left and right arm controllers, discretizing and numerically integrating the expected joint angular velocities at the current moment over the recursive time step to predict the joint angle values ​​for the next moment. To ensure the physical feasibility of the predicted trajectory, after obtaining the predicted joint angle values, the look-ahead simulation module performs secondary anti-overshoot processing on the angle values ​​according to the factory-set mechanical limit ranges for each joint. For the complex spatial Jacobian matrix inverse solution calculations and singularity avoidance processing of the robotic arm, those skilled in the art can use existing robotic forward and inverse kinematics algorithm libraries; the specific derivation process is well-known in the field and will not be elaborated here.

[0124] The look-ahead module uses the predicted chassis pose and predicted joint angles for the next time step, calculated above, as new known state points, and substitutes them into the next iteration to continue the look-ahead calculation. This iterative process continues until the set number of iterations (10) is completed.

[0125] After completing the iterative iteration, the look-ahead module packages and combines the 10 sequentially generated chassis pose state points to construct chassis pose prediction data. Simultaneously, the look-ahead module aggregates the angle change points of all joints across multiple time steps to form the future trajectory prediction data for the dual-arm robot, which is the robot arm trajectory envelope mapped in three-dimensional space. This continuous multi-step prediction sequence demonstrates the robot's response trend to the desired command from a temporal perspective and is temporarily stored in a memory cache, awaiting release to the second control program 20 to participate in the final safe execution arbitration.

[0126] After generating a multi-step prediction sequence, the first control program 10 provided by this invention needs to transmit the calculation results to the execution channel through the prediction publishing module. In order to ensure that the control system can maintain a definite behavioral output in an environment where communication is disrupted or computing power fluctuates, the prediction publishing module is not only responsible for distributing entity prediction data, but also adds timeliness constraints to the batch of data through an independent metadata channel.

[0127] The specific implementation logic for data packaging and timely release in the prediction and release module is as follows:

[0128] First, the prediction and deployment module acquires the chassis velocity upper bound data, robotic arm trajectory prediction data, and chassis pose prediction data output by the look-ahead simulation module. To ensure accurate alignment of multi-source heterogeneous data at the execution end, the prediction and deployment module assigns a unified generation timestamp to each of the aforementioned entity prediction data. This generation timestamp reflects the starting physical time when the current round of sensing data was collected and used for simulation calculations.

[0129] In this embodiment, the prediction publishing module constructs an independent prediction metadata structure. This prediction metadata, as a data stream independent of entity control variables, is used to transmit the real-time health status and data timeliness attributes of the forward-looking projection channel to the second control program 20. The prediction publishing module writes a linearly increasing projection sequence number into the prediction metadata. The projection sequence number is counted from the system power-on initialization phase; it is incremented by one each time the first control program 10 successfully completes a full round of environmental modeling and projection calculation. This projection sequence number is used by the receiving end to verify the continuity of data frames, filtering out historically delayed messages caused by network fluctuations and reducing the risk of old prediction data overwriting new prediction data.

[0130] As a crucial part of the dual-channel security isolation mechanism, the prediction release module calculates and writes a validity period timestamp with an absolute time attribute into the prediction metadata. This validity period timestamp defines the latest time boundary at which the current batch of prediction data is allowed to participate in the arbitration of underlying hardware instructions. When physical time crosses this boundary, the corresponding prediction envelope will no longer be used as a valid control reference. According to system settings, the validity period timestamp is calculated by adding the generation time timestamp to the prediction validity period coefficient and the look-ahead extrapolation period. As the specific calculation logic of the control program in this embodiment, the formula for calculating the validity period timestamp is:

[0131] ;

[0132] in, This indicates the validity period timestamp carried in the prediction metadata; This indicates the timestamp at which the current batch of predicted data was generated; This represents the system's preset prediction validity period coefficient; This indicates the forward projection cycle of the first control procedure 10.

[0133] In industrial field communication, occasional data packet loss is normal. Predicted effective lifespan coefficient. The design aims to provide a reasonable communication fault tolerance window for the control system. Based on the basic algorithm constraint parameters loaded during the system initialization phase, the look-ahead simulation cycle is... Specifically set to 50ms, as a preferred implementation method, the effective period coefficient is predicted. It is specifically set to 2.0. Based on the above settings, the prediction and release module uses the timestamp of the current generation time. Based on this, a fixed extension of 100ms is made towards the future physical timeline, which serves as the boundary for determining the failure of the current predicted envelope. Using the above coefficient settings, the system can smoothly handle communication packet loss within a single simulation calculation cycle, and decisively trigger a security block when two consecutive failures to receive new simulation data occur.

[0134] After completing the coupled calculation of data and timeliness labels, the prediction publishing module publishes entity control packets, such as chassis speed upper limit data and robotic arm trajectory prediction data, along with prediction metadata containing the inference sequence number and validity period timestamp, to the global network environment for downstream nodes to subscribe to via the system communication bus. To prevent logical errors caused by out-of-order delivery of entity data and metadata in asynchronous communication channels, the prediction publishing module identifies entity data packets and metadata data packets with the same timestamp. The receiving end must match the entity control features and metadata timeliness attributes under the same timestamp index to recognize the legitimacy of the frame data. For the data serialization encoding method in the underlying communication environment and the topic publication and subscription mechanism between network nodes, those skilled in the art can use existing distributed computing communication middleware protocols. The underlying network data packet distribution and routing logic is well-known in the field and will not be elaborated here.

[0135] The second control program 20 provided by this invention serves as the system's real-time execution channel, responsible for directly interfacing with the instruction interface of the underlying physical hardware and performing the final control arbitration. To ensure the smoothness of mechanical motion and the immediacy of closed-loop response, the second control program 20 operates on a high-frequency time reference independent of the first control program 10.

[0136] The specific processing logic for high-frequency state acquisition and look-ahead ready gating is as follows:

[0137] In this embodiment, the second control program 20 operates at a fixed control cycle. Execute the main loop task. To match the normal communication refresh frequency of the underlying hardware servo driver, the control cycle... Set to 10ms, its operating frequency is significantly higher than the look-ahead simulation frequency of the first control program 10. Within each control cycle, the second control program 20 acquires the current mileage information of the robot chassis and the latest measured position and velocity status of each robotic arm joint through the status acquisition module. Simultaneously, the second control program 20 extracts the latest batch of entity prediction data and prediction metadata published by the first control program 10 from the system's global communication bus. This asynchronous acquisition architecture, separating high and low frequencies, enables the system to maintain real-time updates of the underlying control command loop while performing time-consuming complex environment simulation calculations.

[0138] During the initial power-on initialization phase, or when the first control program 10 experiences a brief computational delay due to resource scheduling, the look-ahead simulation model often requires a specific time window to complete the fusion of the environmental perception point cloud and the generation of the initial prediction envelope. During this transition phase, the execution channel lacks effective look-ahead prediction data as a safety constraint reference. To prevent the system from directly responding to high-speed expected commands issued by external operators or the navigation planning module during this phase lacking look-ahead data protection, the look-ahead ready gating module within the second control program 20 intervenes in the workflow. The look-ahead ready gating module extracts the latest frame's prediction metadata in real time, checks its timestamp and simulation sequence number, and determines whether the current simulation channel has reached the readiness standard for continuous and stable output.

[0139] In terms of specific judgment logic, the look-ahead ready gating module maintains a counter reflecting the continuous reception status. When the timestamp interval between two adjacent frames of prediction metadata is within a reasonable range, and the inference sequence number remains monotonically increasing, the counter performs an accumulation operation. As a specific implementation, the look-ahead ready gating module only determines that the inference channel has entered a continuously valid ready state when the value of this counter reaches a preset threshold for the number of consecutive received frames. If a communication interruption occurs or the inference sequence number regresses, the counter will be reset to zero. This judgment mechanism compensates for the occasional misjudgment defects that may be caused by single-message verification.

[0140] If the look-ready gating module determines that the predicted metadata is missing or has not yet met the continuous validity condition, it will actively trigger the look-ready gating protection mechanism. During the intervention of this mechanism, the look-ready gating module applies rigid speed amplitude constraints to the chassis's expected motion commands flowing within the system. Generally, the gating safety speed limit is calibrated based on the robot's overall weight and the physical energy absorption limit of its anti-collision buffer structure to ensure that even if the robot experiences an accidental collision under this speed limit, it will not cause structural damage to the environment or the robot itself. As a specific constraint setting in this embodiment, the system presets a gating safety speed limit. The physical value is set to 0.05 m / s at an extremely low speed. The look-ahead gating module handles linear velocity commands related to chassis motion. Apply the following boundary constraint formula:

[0141] ;

[0142] in, This indicates the chassis linear velocity command after being constrained by the look-ahead gating module. This indicates the preset upper limit of the gated safety speed, which is 0.05 m / s. The absolute value symbol is used to ensure that the chassis obeys this constraint boundary in both forward and reverse movements.

[0143] By introducing the aforementioned look-ready gating module's verification and speed limiting mechanism at the control layer, the control system allows operators to make minor, safe adjustments and tentative movements to the robot chassis before the algorithm is ready. At the same time, it effectively prevents high-speed erroneous commands that have not been verified by look-ready calculations from being sent to the underlying hardware, thus ensuring the robot's operational safety in the initial startup phase.

[0144] The arbitration limiting module 40 provided by this invention is located within the second control program 20 and is responsible for resolving execution conflicts when multiple control commands coexist. In actual operation scenarios, the underlying hardware may simultaneously face driving demands from multiple dimensions such as manual operation, automatic navigation, and safety obstacle avoidance. The arbitration limiting module 40, through numerical comparison and envelope constraint mechanisms, uniformly transforms the aforementioned multi-source expected commands into deterministic outputs that conform to safe physical boundaries.

[0145] The specific arbitration logic for fusing multi-source expectation instructions and prediction envelopes is as follows:

[0146] In this embodiment, the arbitration limiting module 40 simultaneously extracts multi-source control data. The arbitration limiting module 40 receives the desired chassis motion command and the desired robotic arm motion trajectory from the host computer human-machine interaction module 90 or the automatic navigation system. Simultaneously, the arbitration limiting module 40 reads the upper limit of the chassis linear velocity, the upper limit of the chassis angular velocity, and the robotic arm trajectory prediction data transmitted by the first control program 10. The aforementioned desired command represents the robot's external operational intent, while the prediction data generated based on environmental constraints constitutes the rigid physical boundary for whether this intent can be safely executed.

[0147] For the linear motion control of the chassis, the arbitration limiting module 40 performs direction retention and amplitude limiting operations on the desired linear velocity command. In the underlying control mechanism, this operation aims to achieve a smooth transition between external operational efficiency and self-collision avoidance safety. When the environmental field of view is open, the upper limit of the chassis linear velocity is at a high level, and the system prioritizes responding to the operator's desired command; when an obstacle approaches, causing a rapid drop in the upper limit of linear velocity, the system will actively intervene and limit the chassis's acceleration capability. To prevent the chassis from exceeding the safety limit given by the forward-looking simulation channel, the arbitration limiting module 40 compares the absolute value of the desired linear velocity with the upper limit of the chassis linear velocity, selecting the smaller value as the safety command amplitude. Based on this, the arbitration limiting module 40 multiplies the safety command amplitude with the original direction sign of the desired linear velocity. As the specific calculation logic of the control program in this embodiment, the calculation formula for the actual chassis linear velocity command is:

[0148] ;

[0149] in, This indicates the actual chassis linear speed command issued after arbitration and synthesis. This indicates the desired speed issued by the operator or navigation system. This represents the upper limit of the chassis linear velocity derived from the calculation of the first control program 10; The function is a symbolic function, used to extract and retain internal independent variables. Positive and negative direction indicators; Functions are used to output arguments. and The minimum value between; Indicates the independent variable Absolute value operation.

[0150] Similarly, for chassis steering motion control, the arbitration limiting module 40 uses consistent limiting synthesis logic to process angular velocity commands. The direction of the actual chassis angular velocity command is consistent with the operator's or navigation's desired angular velocity, and its amplitude is the smaller of the absolute value of the desired angular velocity and the upper limit of the predicted angular velocity given by the look-ahead channel. Through the above component-by-component comparison and synthesis algorithm, the synthesized motion command of the chassis will not exceed the safety boundary of the look-ahead simulation under any circumstances.

[0151] For the motion control of the dual-arm manipulator, the arbitration and limiting module 40 performs trajectory constraint verification based on the predicted envelope. For collaborative scenarios where the mobile dual-arm robot uses both arms to handle the same material, the arbitration and limiting module 40 introduces a dual-arm coordination conflict resolution mechanism. The arbitration and limiting module 40 establishes closed-loop kinematic constraint equations for the end-effectors of the two arms, with the gripping points of both arms as physical constraints. When it detects that the desired trajectories of the left and right arms do not satisfy the above closed-loop kinematic constraint equations in spatial pose, it calculates the internal force coupling residuals of the two arms using the Jacobian matrix and synchronously adjusts the desired joint angles of the two arms according to a preset impedance control admittance model to resolve torque conflicts caused by the physical entanglement between the two arms. The robotic arm has a high degree of freedom of motion in three-dimensional space, and its desired trajectory point set must be strictly constrained by the robotic arm trajectory prediction data. The arbitration and limiting module 40 verifies cycle by cycle whether the desired joint angle falls within the legal envelope range formed by the robotic arm trajectory prediction data after conflict resolution. If the desired joint angle does not exceed this envelope range, the system directly releases the desired command.

[0152] When a desired joint angle is detected attempting to exceed the boundary of the predicted envelope, the arbitration limiting module 40 triggers a trajectory interpolation and degradation limiting mechanism. In one specific implementation, the arbitration limiting module 40 forcibly truncates the exceeding desired joint angle to the critical edge of the predicted envelope. The arbitration limiting module 40 combines the factory-set joint speed limit parameters of the underlying servo motors of each joint with the physical limit threshold of joint acceleration to perform smooth curve interpolation calculations between the current actual joint position and the truncated target critical position. By introducing a dual protection limit of acceleration thresholds, the above interpolation process can generate a flexible transition trajectory that does not exceed physical limits, effectively reducing the risk of severe shaking or transient torque overload failures caused by sudden command changes in the robotic arm. For trajectory interpolation algorithms in high-dimensional space, those skilled in the art can use existing spline interpolation function libraries; the underlying mathematical derivation is well-known in the field and will not be elaborated here.

[0153] After comprehensive processing by the arbitration limiting module 40, the multi-source expected instructions that might have exceeded the limit are transformed into a safe execution sequence that is strictly controlled by the forward extrapolation boundary, providing a reliable source of instruction input for subsequent high-frequency underlying drivers.

[0154] The instruction issuing module provided by this invention is located at the end of the execution loop of the second control program 20. After completing the arbitration synthesis of the above-mentioned multi-source instructions and the corresponding security checks, the control system needs to convert the digital instructions existing in the software memory into actual driving actions of the underlying physical hardware. The instruction issuing module is responsible for receiving the security control sequence processed by the arbitration limiting module 40 and dispatching it to the corresponding underlying execution mechanism at a high frequency.

[0155] The specific execution logic for high-frequency command issuance and communication distribution is as follows:

[0156] In this embodiment, the command issuing module performs global command state aggregation and sampling. Within each 10ms control cycle, the command issuing module extracts the comprehensive motion parameters verified by the system from the shared memory area. These comprehensive motion parameters specifically include the composite linear velocity and composite angular velocity for the mobile chassis, the multi-degree-of-freedom target joint angles for the left and right arm controllers, and the opening and closing target positions for the dual gripper controllers. By establishing a unified aggregation node, the system can maintain the synchronized triggering state of chassis movement operations and robotic arm grasping operations within the same control cycle at the software level.

[0157] After completing the aggregation of instruction parameters, the instruction issuing module adds a unified timestamp to all instruction data in the current batch. Asynchronous bus communication in industrial environments often experiences network jitter at the microsecond to millisecond level. To reduce the impact of network latency on the continuity of underlying mechanical motion, the instruction issuing module retrieves the current system hardware high-precision clock, generates a unified timestamp for the issuance time, and tightly couples and packages this timestamp with the chassis speed instruction and joint trajectory instruction.

[0158] To ensure absolute consistency of timestamps among the first control program 10, the second control program 20, and all underlying physical hardware, the system globally deploys the IEEE 1588 time synchronization protocol to achieve global clock synchronization. The main control unit, acting as the master clock node, periodically broadcasts synchronization messages to all sensors and hardware controllers. Each hardware node compensates for clock deviations based on measured network transmission delays, eliminating the risk of timing misalignment caused by hardware crystal oscillator drift.

[0159] The main control principle behind introducing timestamps lies in establishing a cross-node timing alignment mechanism. On one hand, the timestamp provides a benchmark for verifying the timeliness of instructions to the underlying hardware. After receiving a message, the underlying servo driver node calculates the time difference between the message's timestamp and its local hardware clock. As a preferred setting, if this time difference exceeds a preset maximum allowable communication delay threshold, the underlying node will determine the message as a delayed and discarded packet, thus avoiding unexpected actions caused by centralized processing of historical messages after network congestion recovery. On the other hand, the underlying hardware typically operates at a servo response frequency higher than 10ms. The underlying driver uses the timestamp difference of continuously received instructions and the position increment to calculate the precise instruction transition speed, and then performs kinematic smooth interpolation calculations within a more microscopic control cycle. This mechanism effectively mitigates the mechanical stuttering caused by communication discretization.

[0160] After timing encapsulation is completed, the instruction issuing module performs instruction packet splitting and targeted routing distribution according to the channel mapping rules set by the interface contract loading module 30 during the system initialization phase. For the chassis motion domain, the instruction issuing module encapsulates the timestamped linear velocity and angular velocity instructions into chassis control messages and pushes them to the communication channel corresponding to the differential chassis controller. For the dual-arm operation domain, the instruction issuing module encapsulates the joint trajectory arrays of the left and right arms and the gripper opening and closing instructions separately, and pushes them to the specific communication channels corresponding to the left arm controller, right arm controller, and dual-gripper controller. This targeted routing distribution mechanism isolates the data streams of different types of hardware, preventing data parsing errors in a single actuator from affecting the entire control system.

[0161] The encapsulated instruction messages are ultimately transferred to the hardware abstraction layer of the controller management module 70. The hardware abstraction layer translates the standard instruction structures of the application layer into low-level data frames conforming to a specific industrial bus protocol. Under this mechanism, the controller management module 70 concurrently sends each low-level data frame to the corresponding physical servo drive node according to the low-level bus time slot allocation rules. At this point, the second control program 20 completes a full high-frequency control closed loop, and the physical actuator generates the expected displacement or speed action based on the received safety instructions. For the data structure serialization operations and the low-level bus level signal conversion processes involved in the hardware abstraction layer, those skilled in the art can use existing communication middleware and gateway drivers. The low-level data packet encapsulation and communication handshake logic are well-known technologies in the field and will not be elaborated upon here.

[0162] The method provided by this invention constructs a dual watchdog security verification mechanism independent of the inference source in the second control program 20. Due to the complex industrial electromagnetic environment and the fluctuation of computing power of the vehicle computing platform, the first control program 10 may experience process blocking or communication interruption. This mechanism uses two levels of judgment, namely timeliness verification and update frequency monitoring, to prevent expired or disconnected prediction envelopes from interfering with the underlying physical execution.

[0163] The specific mechanism for preventing failure of the dual watchdog timer is as follows:

[0164] In this embodiment, the second control program 20 initiates a first-level watchdog verification mechanism every 10ms high-frequency control cycle. This verification mechanism is mainly used to verify the validity of the prediction data on the absolute time axis. The second control program 20 extracts the latest frame prediction metadata from the current cache and reads the validity period timestamp contained therein. Synchronously, the second control program 20 calls the high-precision local clock of the execution channel to obtain the current absolute physical time of the system. The second control program 20 compares the current absolute physical time with the extracted validity period timestamp. If the current absolute physical time is greater than the validity period timestamp, the system determines that the batch of prediction data has exceeded the safe validity period range approved at the time of generation.

[0165] As a supplement to the first-level verification, the second control program 20 simultaneously initiates a second-level watchdog verification mechanism. This verification mechanism is mainly used to monitor the update activity of the prediction channel on the relative time axis. The second control program 20 internally maintains a timer independent of the prediction channel. This timer records the time interval elapsed since the last successful reception and parsing of new prediction metadata. If the first control program 10 experiences an abnormal crash or the underlying bus encounters persistent congestion, resulting in the prediction metadata channel not being updated for an extended period, the timer value will continuously accumulate. The second control program 20 compares this timer value with a preset execution-side prediction timeout threshold. Compare them.

[0166] Based on the control system's operating parameter settings, the execution side predicts the timeout threshold. The timeout threshold is specifically set to 200ms. This timeout threshold covers at least three standard look-ahead cycles. When the accumulated value of the timer exceeds this threshold, even if the current cached prediction data still has a theoretical surplus in terms of absolute validity, the system determines that a break has occurred in the prediction data stream.

[0167] Within any control cycle, if either the first-level watchdog or the second-level watchdog triggers a failure condition, the second control program 20 immediately lowers the overall confidence level of the look-ahead channel and determines that the current predicted channel has entered a failure blocking mode. In actual industrial deployments, relying solely on absolute timestamps for determination is susceptible to source system clock malfunctions, while relying solely on local timers cannot identify the risk of data packets being delayed for extended periods in network nodes. This dual-determination logic constitutes a composite fault-tolerance barrier for the system, effectively mitigating the boundary exceedance defects caused by single timestamp anomalies or simple counter overflows.

[0168] Once the prediction channel is determined to be faulty, the second control program 20 forcibly blocks the chassis speed upper limit and robotic arm trajectory prediction data issued by the first control program 10. The blocked data will no longer be used as valid parameters input into the arbitration limiting module 40 for synthetic calculation. Due to the loss of the forward collision safety warning limit, the system reduces the chassis's expected motion permission to a minimum. The second control program 20 generates the highest priority chassis zero-speed protection command, directly overriding and clearing the currently flowing chassis linear velocity and chassis angular velocity commands. Simultaneously, to prevent the transfer of the entire machine's physical inertia caused by sudden chassis braking from impacting the upper robotic arm, the second control program 20 issues a current position hold command to the left and right robotic arm controllers, stopping all predetermined trajectory interpolation actions. Through the above decisive zero-speed blocking operation, the system can maintain a safe parking state in place even when the sensing computing power is offline, preventing the occurrence of out-of-control blind driving accidents. At the same time, the system reports the prediction failure alarm code to the host computer human-machine interaction module 90 or the automatic navigation system through the internal event bus, waiting for the upper-level task scheduling module to initiate the recovery or reset process.

[0169] See attached document Figure 7 ,like Figure 7 As shown, the state machine includes four dynamic transition modes: M0 Normal assist; M1 Speed ​​limiting / degradation (i.e., speed reduction). Multiply by 0.5 (Derate) M2 is pure feedback control, which ignores prediction; M3 is emergency stop, which is a global stop. Its mode switching conditions are set with three thresholds in meters or radians. , , (m or rad): When the deviation is greater than the threshold 1 ( When the deviation exceeds the threshold 2 or the prediction times out, enter M1; when the deviation exceeds the threshold 2 or the prediction times out. When the deviation exceeds the threshold 3 (or timeout), enter M2; when the deviation is greater than ... When an emergency stop (e-stop) is triggered, the system enters state M3. Based on this state machine logic, the deviation monitoring module 50 provided in this invention is located within the second control program 20 and is responsible for constructing a physical closed loop between real-time measured feedback and the look-ahead predicted state. During robot operation, due to interference from physical factors such as changes in ground friction, lag in motor servo response, or mechanical structure play, the robot's actual physical state often deviates from the theoretical state deduced by the look-ahead channel. To address this nonlinear error, the deviation monitoring module 50 drives the control system to dynamically switch between four degradation modes through a real-time error measurement mechanism.

[0170] The specific logic for state deviation monitoring and dynamic switching of the four-level mode is as follows:

[0171] In this embodiment, the deviation monitoring module 50 performs synchronous calculation of the system deviation in each high-frequency control cycle. The deviation monitoring module 50 extracts the measured physical parameters of the chassis and robotic arm at the current moment from the state acquisition module, and simultaneously locates the expected predicted parameters matching the current physical timestamp from the prediction sequence of the look-ahead simulation channel. Subsequently, the deviation monitoring module 50 calculates the difference between the two parameters in the same reference coordinate system using matrix difference operations to obtain the system's current state deviation. As one specific implementation method, the state deviation amount It is not a single-dimensional scalar, but a multi-dimensional vector array that includes the spatial Euclidean distance deviation of the chassis coordinates and the angle deviation of each robotic arm joint.

[0172] The deviation monitoring module 50 introduces three system safety deviation thresholds that increase progressively from low to high, defined as the first deviation threshold. Second deviation threshold and the third deviation threshold In industrial scenario parameter calibration, the aforementioned three-level thresholds are comprehensively defined based on the conventional dynamic lag range of chassis closed-loop control, the deviation tolerance when wheels experience physical slippage, and the extreme runaway boundary that may cause the entire machine to overturn. Furthermore, the system supports independently setting corresponding threshold groups for chassis pose and each joint angle of the robotic arm. Taking the physical dimensions of the chassis control domain as an example, the system presets a first deviation threshold. The specific value is 0.05m, the second deviation threshold. The specific value is 0.15m, the third deviation threshold. The specific value is 0.30m, and the deviation monitoring module 50 will calculate the state deviation in real time. A series of conditional decision branches are fed in, and combined with the validity state value of the predicted data itself, the state machine switches are performed in the four control modes M0, M1, M2 and M3 defined by the system.

[0173] If the current state deviation satisfies (i.e., chassis displacement deviation) ),in This represents the state deviation. The first deviation threshold is indicated, and the dual watchdog verification mechanism confirms the validity of the current prediction data. The deviation monitoring module 50 then maintains or switches the system to M0 mode. M0 mode is defined as the normal look-ahead assist mode. In this mode, the system determines that the following accuracy of the underlying mechanical actuator to the upper-level prediction command is within a healthy range, and the underlying control loop operates normally according to the multi-source fusion command synthesized by the arbitration limiting module 40.

[0174] If the current state deviation diverges, satisfying... (i.e., chassis displacement deviation) ),in This represents the state deviation. Indicates the first deviation threshold. The second deviation threshold is indicated. When the deviation monitoring module 50 determines that the system's physical execution has a significant lag or slight slippage, it triggers the control state machine to degrade to M1 mode. M1 mode is defined as a speed-limited degradation mode. In M1 mode, to allow the underlying servo controller more time to correct tracking errors, the system applies a global speed reduction operation to the currently flowing chassis commands. As a specific processing logic in this embodiment, the system multiplies the current chassis linear velocity and angular velocity commands by a preset attenuation coefficient. Taking an attenuation coefficient of 0.5 as an example, the system performs the following half-speed processing on the speed commands:

[0175] ;

[0176] in, This represents the chassis linear speed command; the constant 0.5 is the preset attenuation coefficient. By introducing this proportional attenuation calculation, the system suppresses further amplification of errors caused by poor closed-loop tracking without interrupting the current task, achieving a smooth degradation of the control dimension.

[0177] If the current state deviation worsens further, then the following condition is met: (i.e., chassis displacement deviation) ),in This represents the state deviation. This indicates the second deviation threshold. This indicates the third deviation threshold, or a failure occurs when the look-ahead channel prediction data times out. In this case, the deviation monitoring module 50 degrades the system to M2 mode. M2 mode is defined as a pure feedback control mode. Entering M2 mode means the system determines that the prediction sequence given by the look-ahead simulation has deviated from the actual physical feedback. In this mode, the deviation monitoring module 50 actively cuts off the data stream input of the first control program 10, ignoring all look-ahead prediction envelopes. The system's underlying controller degenerates into an isolated closed-loop state relying on local odometer and joint encoder measured data for near-field collision avoidance feedback.

[0178] When the state deviation exceeds the limiting physical boundary, it satisfies (i.e., chassis displacement deviation) ),in This represents the state deviation. When the third deviation threshold is reached, or when the system receives a global explicit emergency stop signal, the deviation monitoring module 50 transfers control to the emergency stop module 60, triggering the system to enter M3 mode. M3 mode corresponds to the underlying global emergency stop state, in which the system completely abandons operational continuity and forcibly cuts off all movement.

[0179] The emergency stop module 60 provided by this invention is located within the second control program 20. In actual operation scenarios of industrial robots, when the deviation monitoring module 50 determines that the state deviation exceeds the limit physical boundary and enters M3 mode, or when the control system receives a hardware emergency power-off signal issued by the human operator, the control system needs to cut off the risky movement trend. The emergency stop module 60 achieves global emergency stop and underlying hardware protection by forcibly taking over the control loop and dispatching a safety trajectory.

[0180] The specific action mechanism of this global emergency stop and underlying hardware protection is as follows:

[0181] In this embodiment, after being activated, the emergency stop module 60 acquires control of the instructions within the second control program 20. In the industrial control architecture, the software emergency stop status flag generated by the internal deviation monitoring module 50 and the hardware interrupt signal triggered by the emergency stop button on the vehicle body are converged through an OR operation performed by the interrupt layer of the operating system. An emergency stop signal from any channel can raise the activation level of the emergency stop module 60. The emergency stop module 60 actively blocks the data output link between the arbitration limiting module 40 and the look-ahead simulation module, intercepting all currently flowing conventional expected instructions and prediction sequences. This takeover mechanism ensures that, in an emergency, the system's underlying layer no longer responds to any external inputs with the intention to continue moving.

[0182] For the mobile chassis unit, the emergency stop module 60 performs a chassis speed zeroing operation. Considering the physical inertia of the loaded mobile chassis in motion, as a specific instruction reset logic in this embodiment, the emergency stop module 60 forcibly sets the values ​​of both the linear velocity command and the angular velocity command sent to the chassis to zero. The instruction issuing module sends the above-mentioned zero-speed command to the differential chassis controller. Based on the physical principles of chassis control, after receiving the speed command that drops to zero in a step, the differential chassis controller does not instantly cut off the motor enable. Instead, it calls the maximum deceleration acceleration parameter curve preset in the underlying firmware to drive the underlying servo motor to perform a controlled active electric braking action, so that the robot chassis can park within the anti-collision buffer stroke.

[0183] For the dual-arm operating unit, the emergency stop module 60 sends a safety holding trajectory or a zero-return trajectory to the left arm controller and the right arm controller. The specific mode switching depends on the emergency stop response strategy set in the system's global parameter service. When set to safety holding mode, the emergency stop module 60 extracts the current measured joint angles of each joint of the robotic arm and assigns the target joint angle command for the next cycle to the equivalent measured joint angle. The physical meaning of this operation is to instruct the servo motors of each joint to output a static holding torque that balances the current gravity and load, preventing the robotic arm from falling and being injured due to sudden power failure and loss of lock.

[0184] As a preferred configuration, when the emergency stop response strategy is set to zero-return mode, the emergency stop module 60 plans a transition trajectory from the current measured pose back to the factory-preset safe zero-point pose. To avoid self-interference of the two arms or collision with the vehicle body during the zero-return process, the emergency stop module 60 calls an inverse kinematics algorithm to generate a controlled deceleration smoothing curve in the joint space. The target position commands of each joint converge to the preset safe zero-point coordinates. For the zero-return trajectory planning algorithm of the multi-degree-of-freedom robotic arm in the joint space, those skilled in the art can use existing robot safety control strategies to implement it. Its underlying trajectory generation logic is well-known in the field and will not be described in detail here.

[0185] For the end effector, the emergency stop module 60 sends a status lock command to the dual gripper controller. In the emergency stop state, the dual gripper controller maintains the current closed-loop current and clamping torque, so that the dual grippers maintain the current opening degree, ensuring that the work material held inside the grippers will not accidentally fall off due to the system's sudden stop.

[0186] The command issuing module synchronously packages the aforementioned chassis zero-speed commands, robotic arm safety maintenance or return-to-zero trajectory commands, and gripper locking commands, and attaches a unified emergency state timestamp, bypassing the regular waiting queue and directly dispatching them to the corresponding underlying hardware controller. Upon receiving this set of commands, the underlying physical hardware executes the braking and attitude locking actions of the entire robot. Through this comprehensive intervention mechanism, the control system mitigates the collision risks caused by software and hardware failures or sudden external obstacles, achieving underlying safety protection for the robot body.

[0187] See attached document Figure 8 ,like Figure 8 The diagram shows a comparison of various numerical indicators (see labels for unit) between the single-channel and dual-channel (invention) versions of this invention. Specifically, the root mean square error of linear velocity (Lin RMS (m / s)) decreased by 29% (-29%); the root mean square error of angular velocity (Ang RMS (rad / s)) decreased by 26% (-26%); the emergency stop response time (E-stop (ms)) decreased by 38% (-38%); the near hit (times / 10min) decreased by 86% (-86%); and the control cycle jitter (ms) decreased by 68% (-68%). Comparative testing demonstrates that the failure prediction blocking mechanism and multi-source command arbitration fusion architecture employed in this invention effectively eliminate the risk of expired predictions being executed. Under complex disturbances, the system not only significantly reduces the incidence of near-collision events and greatly shortens the emergency stop time, but also significantly reduces control cycle jitter, thereby improving the safety and closed-loop stability of the entire machine operation.

Claims

1. A dual-channel control method for a mobile dual-arm robot, characterized in that, include: The first control program (10) and the second control program (20) run in parallel in physical memory. The second control program (20) runs at a higher frequency than the first control program (10), and the second control program (20) has ultimate control over the underlying controller. The first control program (10) performs a deduction based on sensor feedback (80) to generate prediction data and prediction metadata containing a valid time stamp. The prediction data includes chassis speed upper limit data and robotic arm trajectory prediction data. The second control program (20) extracts the prediction data, the prediction metadata, and the multi-source expectation instructions input from the outside; The second control program (20) obtains the current absolute physical time of the system and performs timeliness verification on the prediction data by comparing the absolute physical time with the effective period timestamp; If the verification is valid, the second control program (20) performs amplitude limiting synthesis processing on the multi-source expected instruction and the predicted data to generate the final control instruction, which is then sent to the underlying controller to execute the action; If the verification fails, the second control program (20) blocks the predicted data from participating in the synthesis calculation of the control loop, directly overwrites and clears the chassis linear velocity and chassis angular velocity commands that are currently in operation, and sends the current position hold command to the left and right robotic arm controllers.

2. The control method as described in claim 1, characterized in that, The chassis speed upper limit data includes the linear velocity upper limit and the angular velocity upper limit. The first control program (10) generates prediction data and prediction metadata containing a valid time period timestamp, including: Extract point cloud ranging data from LiDAR, visual feature data from RGB camera, and depth image from depth camera. Use extended Kalman filter algorithm to perform spatiotemporal alignment and feature-level fusion of heterogeneous sensor data to output measured perception data. Extract the minimum obstacle distance in front of the machine body, and calculate the upper limit of the linear velocity and the upper limit of the angular velocity of the chassis based on the physical relationship that the minimum obstacle distance decreases monotonically. Historical trajectory data and theoretically predicted trajectory data are extracted to calculate kinematic tracking residuals. The recursive least squares method is used to identify the actual wheel diameter parameters and equivalent wheelbase parameters online, and the model parameters of the robot kinematic model are dynamically updated. Using the measured sensing data as the initial state point, and combining the robot kinematics model with the dynamically updated model parameters with the upper bound of linear velocity and the upper bound of angular velocity, multi-step kinematic recursive calculation is performed to generate the predicted data. Assign a unified generation time timestamp to the predicted data, add the generation time timestamp to the product of the prediction validity period coefficient and the forward projection period, and write the validity period timestamp into the prediction metadata.

3. The control method as described in claim 1, characterized in that, Before obtaining the system's current absolute physical time, a global clock synchronization step is also included: Based on the IEEE 1588 time synchronization protocol deployed in the system, the main control unit periodically broadcasts synchronization messages to the sensors and the underlying controller. Each hardware node performs clock deviation compensation and correction based on the measured network transmission delay to achieve global clock synchronization. The second control program (20) performs timeliness verification on the predicted data and also includes a second-level watchdog verification mechanism to monitor update activity: A timer, independent of the simulation channel, records the elapsed time since the last successful reception and parsing of new simulation metadata; The time interval is compared with a preset execution-side prediction timeout threshold. If the absolute physical time is greater than the validity period timestamp, or the time interval is greater than the preset execution-side prediction timeout threshold, the current prediction channel is determined to have entered a failure blocking mode.

4. The control method as described in claim 2, characterized in that, The multi-source expectation instruction and the prediction data are combined using an arbitration limiting module (40) and then subjected to limiting synthesis processing, including: For the linear motion control and steering motion control of the chassis, the absolute values ​​of the desired linear velocity and the desired angular velocity are compared with the corresponding upper limits of the linear velocity and the angular velocity, respectively. The smaller value is selected as the safety command amplitude, and the safety command amplitude is multiplied by the original direction sign to synthesize it. For the motion control of the dual-arm operation unit, a closed-loop kinematic constraint equation for the end effector of the dual arms is established in the dual-arm collaboration scenario with the grasping points of both hands as physical constraints. When the desired trajectory of the left arm and the desired trajectory of the right arm do not satisfy the closed-loop kinematic constraint equation for the end effector of the dual arms in terms of spatial pose, the internal force coupling residual of the dual arms is calculated by the Jacobian matrix, and the desired joint angle is synchronously adjusted according to the preset impedance control admittance model to resolve the torque conflict. The system verifies cycle by cycle whether the expected joint angle after conflict resolution falls within the legal envelope range formed by the robot arm trajectory prediction data. If an attempt is made to break through the boundary of the legal envelope range, the expected joint angle that exceeds the limit is forcibly truncated to the critical edge position of the prediction envelope. Combining the factory-set joint velocity limit parameters and the joint acceleration physical limit threshold, a smooth curve interpolation calculation is performed between the current actual joint position and the truncated target critical position.

5. The control method as described in claim 1, characterized in that, After the second control program (20) extracts the prediction metadata, it further includes: Verify the timestamp and inference sequence number carried by the predicted metadata; When the timestamp interval between two adjacent frames of predicted metadata is within a reasonable range and the inference sequence number remains monotonically increasing, the counter reflecting the continuous reception status performs an accumulation operation. If the value of the counter does not reach the preset threshold for the number of consecutive received frames, the look-ahead ready gating protection mechanism is triggered, and a rigid speed amplitude constraint is applied to the linear speed command involving chassis motion, limiting the linear speed command involving chassis motion to a preset gating safety speed limit.

6. The control method as described in claim 1, characterized in that, During the parallel operation of the first control program (10) and the second control program (20), the deviation monitoring module (50) also performs real-time monitoring of state deviation and dynamic switching of four-level modes, including: Calculate the difference between the measured physical parameters at the current moment and the expected predicted parameters in the predicted data under the same reference coordinate system to obtain the state deviation. The state deviation is a multi-dimensional vector array that includes the spatial Euclidean distance deviation of the chassis coordinates and the angle deviation of each robotic arm joint. The state deviation is compared with the preset first deviation threshold, second deviation threshold and third deviation threshold by condition judgment branch, and the first deviation threshold, the second deviation threshold and the third deviation threshold are gradually increased from low to high; If the state deviation is less than or equal to the first deviation threshold and the timeliness verification is valid, the system maintains or switches to the normal look-ahead assist mode, and the underlying control loop operates normally in accordance with the final control command.

7. The control method as described in claim 6, characterized in that, The real-time monitoring of execution status deviation and dynamic switching of the four-level mode also include: If the state deviation diverges and satisfies the condition of being greater than the first deviation threshold and less than or equal to the second deviation threshold, the system will be downgraded to a speed limit downgrade mode, and the current chassis linear velocity and angular velocity commands will be multiplied by a preset attenuation coefficient. If the state deviation further deteriorates and is greater than the second deviation threshold and less than or equal to the third deviation threshold, it is downgraded to a pure feedback control mode, actively cutting off the data flow input of the first control program (10), and the underlying controller degenerates into an isolated closed-loop state that relies on measured data for near-distance anti-collision feedback.

8. The control method as described in claim 6, characterized in that, If the state deviation exceeds the limit physical boundary and is greater than the third deviation threshold, or if a hardware emergency power-off signal is received from a manual operator, the emergency stop module (60) implements global emergency stop and underlying hardware protection, including: Actively block the data output link to intercept all flowing regular expected instructions and prediction sequences; Force the values ​​of both linear velocity and angular velocity commands sent to the chassis to be set to zero; Send a safety holding trajectory or a zero return trajectory to the left arm controller and the right arm controller. Sending the safety holding trajectory includes extracting the current measured joint angle of each joint of the robotic arm and assigning the target joint angle command of the next cycle to the measured joint angle. Send a status lock command to the dual gripper controller to maintain the current current closed loop and clamping torque.

9. The control method as described in claim 1, characterized in that, Before the underlying controller executes the action, it also includes control logic that is activated in a stepped sequence: The controller management module (70) instantiates a controller state mapping table in the system memory. The controller state mapping table is used to record the current running state of the underlying controller. The activation tasks of the underlying hardware are arranged according to a preset tiered time sequence, and the current running status word of the corresponding controller is queried when the target time node is reached. If the current running status word indicator has not been activated, send an activation command message and wait for a confirmation heartbeat signal within the tolerance time window; If the confirmed heartbeat signal is captured, the status word will be updated to "Active and Ready". If the tolerance time window is exceeded, a cyclic retry mechanism based on a preset maximum number of retries will be triggered.

10. A dual-channel control system for a mobile dual-arm robot, used to implement the dual-channel control method for a mobile dual-arm robot as described in any one of claims 1 to 9, characterized in that, include: The first control program (10) is used to perform a deduction based on sensor feedback (80) to generate prediction data and prediction metadata containing a valid time stamp. The prediction data includes chassis speed upper limit data and robotic arm trajectory prediction data. The second control program (20) runs in parallel with the first control program (10) in physical memory. The second control program (20) runs at a higher frequency than the first control program (10), and the second control program (20) has ultimate control over the underlying controller. The second control program (20) is set as follows: Extract the predicted data, the predicted metadata, and the multi-source expectation instructions input from external sources; Obtain the current absolute physical time of the system, and verify the timeliness of the predicted data by comparing the absolute physical time with the valid period timestamp; If the verification is valid, the multi-source expected instruction and the predicted data are subjected to amplitude limiting synthesis processing to generate the final control instruction, which is then sent to the underlying controller to execute the action. If the verification fails, the predicted data is blocked from participating in the synthesis calculation of the control loop. The currently circulating chassis linear velocity and chassis angular velocity commands are directly overwritten and cleared, and the current position hold command is sent to the left and right robotic arm controllers.

Images