Body-aware robot control method, electronic device, medium and product

Abstract

The application discloses a body intelligent robot control method, electronic equipment, medium and product, and belongs to the technical field of robots. The body intelligent robot control method comprises the following steps: forming a task queue of a target robot based on a task of the target robot; extracting a target task from the task queue in the case that the target robot is in an idle state; calculating an execution parameter of a target part associated with the target task of the target robot according to task information of the target task, generating a control instruction based on the execution parameter; controlling the target part through the control instruction, and switching the state of the target robot to the idle state in the case that the target task is completed. The application improves the accuracy and reliability of robot control.

Description

Technical Field

[0001] This application relates to the field of robotics technology, specifically to a control method, electronic device, medium, and product for an embodied intelligent robot. Background Technology

[0002] Robots have wide applications in industrial assembly, service, and scientific research. With the development of robotics technology, the requirements for accuracy and reliability in performing continuous tasks are increasing. Currently, multi-task execution is prone to issues such as instruction conflicts, repetitive execution, and disordered execution order, leading to low accuracy and reliability in robot control. Summary of the Invention

[0003] This invention provides a method, electronic device, medium, and product for controlling an embodied intelligent robot, aiming to improve the accuracy and reliability of robot control.

[0004] Firstly, a method for controlling an embodied intelligent robot is provided, comprising the following steps: Based on the tasks assigned to the target robot, a task queue corresponding to the target robot is formed; When the target robot is in an idle state, the target task is extracted from the task queue; Based on the task information of the target task, calculate the execution parameters of the target robot and the target part associated with the target task, and generate control commands based on the execution parameters; The target part is controlled by the control command, and the target robot is switched to an idle state when the target task is completed.

[0005] In some of these design approaches, the method further includes: If the target part is not in a remote control enabled state, perform the step of calculating the execution parameters of the target robot and the target part associated with the target task based on the task information of the target task; If the target location is in a remote control enabled state, the target task will be stopped.

[0006] In some of these design approaches, after the target task is stopped, the method further includes: If the remote control enable state of the target part is detected to be deactivated, the target task is re-executed, or a new target task is executed.

[0007] In some design approaches, the target part includes a target joint, and the calculation of execution parameters of the target robot associated with the target part based on the task information of the target task includes: When the task information indicates that the target task is a first type of motion task, the target parameters of the target part are obtained from the task information and used as the execution parameters of the target part. When the task information indicates that the target task is a second type of motion task, based on the pre-determined kinematic chains associated with robot body parts, the target kinematic chain corresponding to the target part is determined, the state parameters of each joint in the target kinematic chain are obtained, and the target end pose of the target robot is obtained from the task information. Based on the state parameters, the target end pose and the inverse kinematic function, the execution parameters of the target part are calculated.

[0008] In some of these design approaches, the method further includes: If the execution parameters are within a preset safety range, the step of generating control instructions based on the execution parameters is executed; If the execution parameters are outside the preset safety range, stop executing the target task, or adjust the execution parameters of the target part to a preset value and continue executing the step of generating control instructions based on the execution parameters.

[0009] In some design embodiments, controlling the target part via the control command includes: The control command is sent to the control unit corresponding to the target part through the first communication channel of the first communication port to control the target part; The method further includes: The second communication channel of the first communication port receives the status information of the target part fed back by the control unit during the movement of the target part.

[0010] In some of these design approaches, the method further includes: A remote operation mode switching command is sent to the control unit of the target part through the second communication port to switch the control mode of the target part to the remote operation mode. If the control unit is in a state of responding to the control command to control the target part when it receives the remote operation mode switching command, the execution of the control command is interrupted and the control mode of the target part is switched to the remote operation mode.

[0011] In some design embodiments, after receiving the state information of the target part fed back by the control unit during the movement of the target part, the method further includes: Obtain the target information corresponding to the target location from the task information; If the deviation between the status information and the target information is less than or equal to a preset threshold within a preset execution time, the target task is determined to be completed. If the deviation between the status information and the target information exceeds a preset threshold within a preset execution time, the target task is determined to have failed.

[0012] In some design embodiments, the target robot is configured with multiple data buffers, and after receiving the state information of the target part fed back by the control unit during the movement of the target part, the method further includes: The state information is written into the data buffer pointed to by the first atomic pointer corresponding to the write operation; In response to a status information read operation, the status information is read from the data buffer pointed to by the second atomic pointer corresponding to the read operation; After the state information write operation is completed, the data buffers pointed to by the first atomic pointer and the second atomic pointer are swapped.

[0013] In some of these design approaches, multiple parts of the target robot are each provided with atomic variables, which are used to store the remote control status data of the corresponding parts. After receiving the status information of the target part fed back by the control unit during the movement of the target part, the method further includes: Obtain remote control status data from the status information; Based on the acquired remote control status data, update the values ​​of the atomic variables in the corresponding parts; Read the values ​​of the atomic variables of the target location to determine whether the target location is in a remote control enabled state.

[0014] In some of these design approaches, the process of acquiring the task for the target robot includes: If a new task file is detected in a specified storage address, the task file is parsed to obtain the task for the target robot. And / or, receive task instructions for the target robot via network communication, and parse the task instructions to obtain the task for the target robot.

[0015] In some of these design approaches, the method further includes: The state of the target robot is maintained by a task state machine, and the state includes at least an idle state, an executing state, a waiting state, an error state, and a paused state.

[0016] Secondly, an electronic device is also provided, including a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to execute the steps of any of the embodied intelligent robot control methods provided in the embodiments of this application.

[0017] Thirdly, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the steps of any of the embodied intelligent robot control methods provided in embodiments of this application.

[0018] Fourthly, embodiments of this application also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in any of the embodied intelligent robot control methods provided in embodiments of this application.

[0019] Beneficial effects: By adding tasks targeting the robot to a task queue, multiple tasks can be managed in an orderly manner, avoiding confusion in task execution order. Retrieving target tasks from the queue when the target robot is idle can prevent instruction conflicts caused by multiple tasks being executed simultaneously. Calculating execution parameters for relevant target parts of the target robot based on the task information and generating control commands ensures precise matching between control commands and task requirements. Switching the target robot back to an idle state after the target task is completed allows subsequent tasks in the task queue to be processed in sequence, thereby improving the overall accuracy and reliability of robot control. Attached Figure Description

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

[0021] Figure 1 This is a flowchart illustrating the embodied intelligent robot control method provided by an exemplary embodiment of this disclosure; Figure 2 This is a schematic diagram of the architecture of the embodied intelligent robot control system provided by an exemplary embodiment of this disclosure; Figure 3 This is another flowchart illustrating the embodied intelligent robot control method provided by an exemplary embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of the embodied intelligent robot control device provided in an exemplary embodiment of this disclosure; Figure 5This is a schematic diagram of the internal structure of an electronic device provided in an exemplary embodiment of this disclosure. Detailed Implementation

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

[0023] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0024] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0025] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration to devices performing additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, because processes, steps, calculations, or other actions "based on" one or more of the stated conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated.

[0026] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0027] With the development of robotics technology, dual-arm + torso robots are widely used in industrial assembly, service, and scientific research. Traditional robot control methods typically rely on the ROS (Robot Operating System) framework. While this approach leverages the rich function libraries and toolchains provided by ROS, it also suffers from the following problems: Over-reliance on the ROS framework: The ROS framework itself contains a large number of middleware and dependency libraries, which makes method deployment complex and consumes a lot of system resources, making it unsuitable for use on resource-constrained embedded platforms or in scenarios with high real-time requirements.

[0028] Insufficient real-time performance: ROS's communication mechanisms (such as topics and services) are based on middleware, which results in a certain communication delay, making it difficult to meet the real-time requirements of high-frequency joint control.

[0029] High coupling: Existing control methods often tightly couple functions such as joint driving, kinematic calculation, and task orchestration, resulting in poor scalability and maintainability, and making it difficult to adapt to different hardware platforms and task requirements.

[0030] Switching between remote control mode and planning mode is difficult: Traditional methods usually separate remote control and planning control into different subsystems, making it difficult to flexibly switch the control modes of different body parts in the same task sequence, and failing to achieve seamless coordination between remote control and planning.

[0031] Limited task orchestration capabilities: The lack of a unified task orchestration mechanism makes it difficult to support advanced functions such as complex task sequences, loop execution, and conditional judgments.

[0032] To address the aforementioned issues, this application provides an embodied intelligent robot control method, an embodied intelligent robot control device, an electronic device, a computer-readable storage medium, and a computer program product. By adding tasks for the target robot to a task queue, multiple tasks can be managed in an orderly manner, avoiding confusion in task execution order. Extracting the target task from the queue when the target robot is idle prevents instruction conflicts caused by simultaneous execution of multiple tasks. Calculating execution parameters for relevant target parts of the target robot based on the task information of the target task and generating control instructions ensures precise matching between control instructions and task requirements. Switching the target robot's state back to idle after the target task is completed allows subsequent tasks in the task queue to be processed sequentially, thereby improving the overall accuracy and reliability of robot control.

[0033] On the one hand, such as Figure 1 The diagram shown is a flowchart illustrating an exemplary embodiment of the embodied intelligent robot control method provided in this disclosure. The embodied intelligent robot control method includes steps S11-S14: S11. Based on the tasks for the target robot, form a task queue corresponding to the target robot.

[0034] Specifically, the tasks for the target robot can come from various sources, such as monitoring task files in a specified directory, receiving remote control commands through network communication, or being generated by internal scheduling logic. The target robot can be an embodied intelligent robot.

[0035] Upon receiving a task, it is added to the task queue in the order of receipt or priority. The task queue can use a first-in, first-out (FIFO) data structure, or it can be sorted according to task type or urgency.

[0036] By storing tasks in a queue, multiple tasks can be managed in an orderly manner, avoiding the chaos in execution order caused by disorganized tasks. This allows for a clear understanding of the execution order of all tasks to be executed when dealing with batch or continuous tasks.

[0037] In some embodiments, the process of acquiring the task for the target robot includes: If a new task file is detected in a specified storage address, the task file is parsed to obtain the task for the target robot. And / or, receive task instructions for the target robot via network communication, and parse the task instructions to obtain the task for the target robot.

[0038] In this embodiment, two task acquisition methods are supported. These two methods can be used individually or simultaneously to meet the task input requirements in different scenarios.

[0039] The first task acquisition method is file-driven, which continuously monitors a pre-specified storage address (e.g., a directory path such as "tasks / box / "). When a new task file is detected at this storage address, it first confirms whether the writing of the task file has been completed (e.g., by checking if the file size is stable or using a file locking mechanism) to avoid reading an incomplete file. After confirming the new task file is complete, it reads the content of the new task file. The new task file can be in JSON format, and then parses the new task file.

[0040] The content of a new JSON-formatted task file can be one of three forms: a single task object (e.g., a joint motion task), an array of task objects (e.g., multiple tasks executed sequentially), or a structure containing a loop block that defines an array of tasks and the number of times those tasks need to be repeated. After parsing, one or more tasks are generated based on the file content. If the file contains a single task object, one task is generated; if it contains an array of task objects, multiple tasks are generated in the order of the array; if it contains a loop block, the task array within the loop block is expanded into multiple tasks based on the number of repetitions (e.g., if the loop count is 3 and the array contains 2 tasks, 6 tasks are generated). All generated tasks are added to the task queue in the order they appear in the task file. After a task file is successfully parsed and added to the queue, it can be moved to the processed directory or deleted to prevent duplicate execution.

[0041] This file-driven approach allows users to define robot workflows in batches by editing task scripts offline, without having to send each instruction online in real time.

[0042] The second task acquisition method is network-driven. It continuously listens for task commands from remote clients or consoles via network communication protocols (such as ZeroMQ (ZeroMessage Queue, a high-performance asynchronous messaging library) or TCP / IP (Transmission Control Protocol / Internet Protocol)). When a task command is received, it is validated (e.g., data integrity checks). The command format can be a serialized format (e.g., Protobuf (Protocol Buffers, a cross-platform data serialization protocol)). The command is then parsed to reconstruct the task information. The parsed task is added to a task queue, awaiting scheduling and execution. The network-driven method supports remote real-time control, allowing new tasks to be issued during robot operation.

[0043] The two methods can coexist. For example, a file monitoring thread and a network receiving thread can be started at the same time. Regardless of whether the task comes from a file or the network, it is converted into an internal task format and added to the same task queue, and then scheduled and executed in sequence by the task state machine.

[0044] In this embodiment, by providing two task acquisition methods, namely file-driven and network-driven, it can adapt to two application scenarios: offline scripted operations and online real-time control.

[0045] S12. If the target robot is in an idle state, extract the target task from the task queue.

[0046] Specifically, the state of the target robot can be maintained through a task state machine, which includes at least the following states: Idle, Exactive, Waiting, Error, and Paused. The Idle state indicates that there are no tasks currently being executed, and new tasks can be scheduled; the Exactive state indicates that a task is being processed; the Waiting state indicates that the current task is temporarily suspended due to certain conditions not being met (e.g., waiting for an external signal or the remote control mode being released); the Error state indicates that an error occurred during task execution; and the Paused state indicates that the task is paused but can be resumed later.

[0047] Each time a task is scheduled, the current state of the task state machine is checked first. If the task state machine is in an idle state, one or more tasks are retrieved from the head of the task queue (or the position specified by other priority policies) as the target task, and then the task state machine is switched from the idle state to the execution state. If the task state machine is currently in the execution state, no new task is retrieved, but the current task is waited for to be completed before the next scheduling.

[0048] In this embodiment, this task state machine-based scheduling mechanism can prevent instruction conflicts caused by the simultaneous execution of multiple conflicting tasks, ensuring that only one task or task combination (where the tasks in the task combination do not conflict) is in execution at any given time, thereby guaranteeing the atomicity and security of the control logic. Furthermore, the state transition operations of the task state machine are lightweight and will not affect real-time performance.

[0049] S13. Based on the task information of the target task, calculate the execution parameters of the target robot and the target part associated with the target task, and generate control commands based on the execution parameters.

[0050] Specifically, each task carries task information, which may include the task type (e.g., joint motion, end effector motion, gripper control, etc.) and the corresponding target value. After obtaining the target task, based on its task information, it is determined which or more target parts of the target robot (e.g., left arm, right arm, torso, gripper, etc.) are involved in the target task. Then, depending on the task type, an appropriate calculation method is used to obtain the specific parameters that need to be executed for the target part. For example, if the target task specifies the angle value of the target joint, then that angle value is used as the execution parameter; if the target task specifies the target pose of the end effector, then inverse kinematics solution needs to be performed in conjunction with the current kinematic state to obtain the angle values ​​of each joint as the execution parameters. Here, the end effector refers to the device installed at the end of the robot arm to perform specific operations, such as a gripper, suction cup, or dexterous hand; pose includes position and orientation information. Kinematic state refers to the current angle values ​​of each joint of the robot and the calculated position and orientation of the end effector. Inverse kinematics refers to the calculation method of reversing the angle values ​​that each joint of the robot needs to achieve based on the desired pose of the end effector.

[0051] After obtaining the execution parameters of the target part, they can be encapsulated into a control instruction format that can be recognized by the underlying hardware (such as an instruction format containing fields such as joint index, target position, velocity, and acceleration).

[0052] In this embodiment, by calculating the execution parameters in a targeted manner based on the task information, the control commands can be precisely matched with the task requirements, reducing unnecessary repetitive movements or erroneous actions.

[0053] S14. Control the target part through the control command, and switch the state of the target robot to idle state when the target task is completed.

[0054] Specifically, the control commands generated in step S13 are sent to the joint actuators or control units corresponding to the target robot through the appropriate communication channels to drive the target part to move according to the control commands. During the movement, the joint status feedback (such as actual position, speed, etc.) can be continuously received and compared with the target value in the task information to determine whether the task has been completed. When it is detected that the target part has reached the expected position or posture and meets the preset completion conditions (such as continuous stability for a certain period of time, deviation less than a threshold, etc.), the target task is considered to be completed. At this time, the state of the task state machine is switched from the execution state to the idle state, so that the next task in the task queue can be extracted and executed.

[0055] In this embodiment, after the task is completed, the state of the task state machine is switched to the idle state (the state of the target robot is also switched to the idle state). This enables subsequent tasks in the task queue to be processed in sequence, ensuring continuity and reliability in multi-task scenarios, and improving the accuracy of robot control and task execution efficiency.

[0056] In some embodiments, the method further includes: If the target part is not in a remote control enabled state, perform the step of calculating the execution parameters of the target robot and the target part associated with the target task based on the task information of the target task; If the target location is in a remote control enabled state, the target task will be stopped.

[0057] Specifically, after the task state machine retrieves the target task from the task queue and switches to the execution state, but before executing the motion control corresponding to the target task, it first checks whether the target body part involved in the target task is in a teleoperation-enabled state. A teleoperation-enabled state means that the target body part (e.g., left arm, right arm, or torso) is set to receive real-time control signals from a remote operating device (such as a handle or motion capture device), rather than receiving planned control commands. Each target body part can be in a teleoperation-enabled or non-teleoperation-enabled state independently; for example, the left arm may be in teleoperation mode while the right arm is in planning mode.

[0058] The status of the target part is determined by querying the teleoperation enable flag (e.g., a Boolean variable) corresponding to it. If the query result shows that the target part is not in a teleoperation enabled state, the subsequent steps continue, namely calculating execution parameters and generating control commands based on the task information of the target task. If the query result shows that the target part is in a teleoperation enabled state, it means that the target part is currently being controlled by the operator in real time. If motion commands are issued at the same time, a conflict will occur between the two, which may lead to abnormal movement of the target robot or danger. Therefore, it is necessary to immediately stop the execution of the current target task, stop the calculation of execution parameters and the sending of control commands, and switch the task state machine from the execution state to the waiting state. This indicates that the target task is temporarily suspended because the teleoperation mode occupies the target part, but the target task is not abandoned; instead, it is suspended, and the teleoperation enable status of the target part is continuously monitored.

[0059] In this embodiment, by adding a check for remote control enable status before calculating execution parameters, command conflicts between planning tasks and remote control can be effectively avoided, ensuring the safe operation of the robot in hybrid control mode. Simultaneously, placing conflicting tasks in a waiting state instead of directly discarding or reporting errors provides the possibility for automatic resumption of execution after subsequent remote control is lifted, achieving seamless collaboration between remote control mode and planning mode within the same task sequence.

[0060] In some embodiments, after stopping the execution of the target task, the method further includes: If the remote control enable state of the target part is detected to be deactivated, the target task is re-executed, or a new target task is executed.

[0061] Specifically, when the task state machine switches to a waiting state because the target part is in a remotely enabled state, it does not discard the target task, but keeps it in the current execution position of the task queue and enters the waiting monitoring phase. It continuously obtains the remotely enabled state information of the target part, for example by periodically reading the remotely enabled flag corresponding to the target part (a boolean variable, true indicates that it is in a remotely enabled state, and false indicates that it has been deactivated).

[0062] The deactivation of the telecontrol enable state may originate from the operator actively shutting down the telecontrol device, switching control modes, or the telecontrol connection automatically disconnecting after a timeout. Once the telecontrol enable flag of the target part changes from true to false, indicating that the telecontrol enable state has been deactivated, the state recovery process is triggered. At this time, the task state machine is switched from the waiting state to the execution state, and the current target task is re-executed, or a new target task is executed. Re-execution means starting from the task information of the original task again, recalculating the execution parameters, generating control commands, and sending them to the target part. The reason for re-execution rather than continuing from the interruption point is that the robot may have moved during the waiting period through telecontrol, and the original execution parameters may no longer be applicable. Recalculation ensures that the control commands are based on the latest robot state. Regarding the execution of a new target task, the next task can be extracted from the task queue (such as a new task specified by the user or a high-priority task in the task queue) as the current execution object, while the original target task is marked as canceled, placed back to the end of the queue, or processed in other ways according to the configuration. This branch is suitable for scenarios where the user wants to skip the original task after telecontrol intervention or where the original task is no longer necessary to execute.

[0063] This step allows users to choose to resume interrupted planned tasks or switch to a new task after the remote control mode is deactivated, without manual intervention or reassignment of tasks, thus improving the continuity and automation of task execution. Simultaneously, the combination of the waiting state and automatic recovery enables safe switching between remote control and planning modes within the same task sequence, ensuring the priority of real-time control without losing planned tasks awaiting execution.

[0064] In some embodiments, the target part includes a target joint, and the step of calculating the execution parameters of the target robot associated with the target part of the target task based on the task information of the target task includes: When the task information indicates that the target task is a first type of motion task, the target parameters of the target part are obtained from the task information and used as the execution parameters of the target part. When the task information indicates that the target task is a second type of motion task, based on the pre-determined kinematic chains associated with robot body parts, the target kinematic chain corresponding to the target part is determined, the state parameters of each joint in the target kinematic chain are obtained, and the target end pose of the target robot is obtained from the task information. Based on the state parameters, the target end pose and the inverse kinematic function, the execution parameters of the target part are calculated.

[0065] Specifically, the task information of the target task includes a task type field, which is used to distinguish different types of motion tasks. In this embodiment, motion tasks are divided into first-type motion tasks and second-type motion tasks based on whether inverse kinematics solution is required.

[0066] The first type of motion task refers to tasks that do not require inverse kinematics solutions and can directly obtain target parameters from the task information as execution parameters. This type of task includes, but is not limited to: joint space motion (e.g., left arm joint motion, right arm joint motion, trunk joint motion, whole body joint motion, directly specifying the target angle values ​​for each joint), dexterous hand control, two-finger gripper control, three-finger gripper control, or four-finger gripper control (directly specifying the target opening angle or grip strength), chassis movement (directly specifying the target movement distance, movement speed, or target heading angle), and offline trajectory execution (directly specifying a pre-recorded sequence of joint angle trajectory points or an end-effector pose trajectory point sequence). For offline trajectory execution, the trajectory sequence can be read from the task information, and each trajectory point can be output sequentially as an execution parameter.

[0067] The second type of motion task refers to tasks that require inverse kinematics solutions, including Cartesian space motion (e.g., requiring the end effector to move to a certain position in space) and pose shift motion (e.g., shifting from the current pose). For this type of task, the task information does not directly provide the angle values ​​of each joint, but rather the target pose of the end effector (including position coordinates and attitude angles). To obtain the required angle values ​​for each joint, kinematic solutions are needed. Specifically, first, based on the target part involved in the target task (e.g., the left arm), the corresponding target kinematic chain is determined from the pre-established kinematic chains associated with robot body parts. A kinematic chain is a series of joints and links connected from the robot base to the end effector, with each body part (e.g., left arm, right arm, torso) corresponding to an independent kinematic chain. Then, the current state parameters of each joint in the target kinematic chain are obtained, i.e., the current actual angle values ​​of each joint (which can be obtained from joint state feedback). Finally, the target end effector pose is read from the task information. Finally, the inverse kinematics function is called, taking into account the current state parameters of each joint (as initial values ​​for the solution) and the target end-effector pose. After numerical iterative calculation, the target angle values ​​of each joint are output, and these angle values ​​are used as the execution parameters for the target part. Inverse kinematics is a method for calculating joint angles from a known end-effector pose, which is the opposite of forward kinematics (which calculates the end-effector pose from a known joint angle).

[0068] In this embodiment, by using whether inverse kinematics solution is required as the dividing criterion, the first type of task directly reads the parameters, while the second type of task automatically completes the conversion from pose to joint angle, which reduces the complexity of task programming and improves the automation level of motion planning.

[0069] In some embodiments, the method further includes: If the execution parameters are within a preset safety range, the step of generating control instructions based on the execution parameters is executed; If the execution parameters are outside the preset safety range, stop executing the target task, or adjust the execution parameters of the target part to a preset value and continue executing the step of generating control instructions based on the execution parameters.

[0070] Specifically, after calculating the execution parameters of the target parts involved in the target task (such as the target angle values ​​of each joint, the opening and closing degree of the gripper, the chassis movement distance, etc.), but before generating control commands, it is necessary to perform a safety check on the execution parameters. The purpose of the safety check is to prevent damage to the robot or danger caused by abnormal parameters (such as exceeding mechanical limits, excessive speed, excessive acceleration, etc.).

[0071] In this embodiment, a safety range is pre-set for each execution parameter, such as the angle limit (minimum and maximum value) of each joint, the stroke range of the gripper opening and closing degree, and the upper limit of the chassis moving speed. The calculated execution parameters are compared with the corresponding preset safety ranges.

[0072] If the execution parameters are within the preset safety range, the parameters are considered safe and valid, and subsequent steps can continue, i.e., generating control commands based on the execution parameters and sending them to the target part. If the execution parameters are outside the preset safety range, the parameters pose a safety risk, triggering the safety protection mechanism. In this case, one of the following two approaches can be taken: The first approach is to directly stop executing the current target task, cease generating control commands, and switch the task state machine to an error state. The task will be terminated, requiring external intervention or a re-issuance of the task. The second approach is to adjust the execution parameters to a value within the preset safety range (e.g., a safety boundary value, a default value, or a predefined conservative value), and then continue executing the steps of generating control commands based on the adjusted execution parameters, enabling the robot to safely complete approximate actions of the task or enter a safe state.

[0073] In this embodiment, by adding a safety verification step after parameter generation and before instruction transmission, safety issues such as mechanical collisions and over-limit movements caused by parameter errors or anomalies can be prevented, thus improving the reliability and safety of robot control. Simultaneously, providing parameter adjustment options allows operation to continue even when encountering non-fatal boundary violations, enhancing fault tolerance.

[0074] In some embodiments, controlling the target area via the control command includes: The control command is sent to the control unit corresponding to the target part through the first communication channel of the first communication port to control the target part; The method further includes: The second communication channel of the first communication port receives the status information of the target part fed back by the control unit during the movement of the target part.

[0075] Specifically, the control unit (e.g., the main controller of the target robot) and the underlying control unit of the target robot (e.g., joint drive board, gripper controller, etc.) adopt a communication mechanism based on UDP (User Datagram Protocol, a connectionless, unreliable but real-time transport layer protocol). The control unit allocates a first communication port (e.g., a fixed UDP port number) for communication with the underlying control unit.

[0076] On the first communication port, the control terminal establishes two communication channels: the first communication channel is used to send control commands, and the second communication channel is used to receive status information. It should be noted that these two communication channels can share the same UDP port, achieving bidirectional communication by distinguishing the flow of data packets (sending and receiving); alternatively, they can use different sockets but be bound to the same port. The control terminal encapsulates the control commands generated in step S13 (e.g., commands containing fields such as joint index, target position, velocity, and acceleration) into UDP data packets via the first communication channel and sends them to the control unit corresponding to the target part. Upon receiving the control commands, the control unit drives the motor or actuator to move. During the movement, the control unit continuously collects the actual status of the target part (e.g., the actual angle and velocity of the joint), encapsulates this status information into UDP data packets, and feeds it back to the control terminal via the second communication channel.

[0077] In this embodiment, network configuration is simplified by using the same first communication port for both control command transmission and status information reception. Simultaneously, the UDP-based communication method avoids the latency caused by TCP (Transmission Control Protocol, a connection-oriented, reliable transport layer protocol) connection establishment and congestion control, meeting the real-time requirements of high-frequency joint control (e.g., 100Hz). Furthermore, independent transmission and reception channels allow for parallel processing of control command issuance and status information feedback, improving communication efficiency.

[0078] In some embodiments, the method further includes: A remote operation mode switching command is sent to the control unit of the target part through the second communication port to switch the control mode of the target part to the remote operation mode. If the control unit is in a state of responding to the control command to control the target part when it receives the remote operation mode switching command, the execution of the control command is interrupted and the control mode of the target part is switched to the remote operation mode.

[0079] In this embodiment, the control mode of the target part can be switched during robot operation, i.e., from planning mode (controlled by the control terminal) to remote control mode (operated by the operator in real time via a remote control device). To achieve this function, in addition to the first communication port used for sending control commands and receiving status information, a separate second communication port (e.g., another fixed UDP port number) is set up between the control terminal and the underlying control unit. This second communication port is dedicated to sending remote control mode switching commands and is separate from the control command sending channel to ensure the real-time performance and reliability of the switching command and avoid switching delays caused by congestion or blockage of the control command channel.

[0080] When it is necessary to switch a target body part (such as the left arm, right arm, or torso) to remote control mode, the control terminal sends a remote control mode switching command to the corresponding control unit through the second communication port. This switching command can be a data packet containing the identifier of the target body part (such as the number of the left arm) and the desired mode (remote control enabled). After receiving the switching command, the control unit checks whether it is currently responding to a control command previously sent by the control terminal. If the control unit is currently responding to a control command (such as driving a motor to move along a planned trajectory), it will immediately interrupt the execution of the current control command, stop the ongoing movement, and then switch the control mode of the target body part to remote control mode. Afterward, the control unit will no longer respond to planned control commands from the control terminal, but will instead receive and execute real-time control signals from the remote control device. If the control unit is not currently responding to a control command (such as being idle or stopped), it will directly switch to remote control mode.

[0081] In this embodiment, by setting up an independent second communication port to send switching commands, the remote control mode can be instantly seized, ensuring that the operator can quickly gain control of the robot in emergency situations or when manual intervention is required, thereby improving safety and the flexibility of human-machine collaboration.

[0082] In some embodiments, after receiving the state information of the target part fed back by the control unit during the movement of the target part, the method further includes: Obtain the target information corresponding to the target location from the task information; If the deviation between the status information and the target information is less than or equal to a preset threshold within a preset execution time, the target task is determined to be completed. If the deviation between the status information and the target information exceeds a preset threshold within a preset execution time, the target task is determined to have failed.

[0083] Specifically, during the process of driving the target part to move through control commands at the control end, it is necessary to continuously determine whether the target task has been completed, or whether a timeout or error has occurred. To this end, when the control end begins executing the target task, it extracts target information from the task information. The specific content of the target information depends on the task type: for joint space motion tasks, the target information can be the target angle values ​​of each joint; for Cartesian space motion tasks, the target information can be the target pose of the end effector; for gripper control tasks, the target information can be the target opening degree or gripping force, etc. Simultaneously, the control end also obtains the preset execution duration (i.e., the maximum allowed execution time) and the preset deviation threshold (used to determine whether the target has been achieved) from the task information.

[0084] During the movement, the control unit continuously receives status information (such as actual joint angles, actual end-effector pose, and actual gripper opening / closing degree) from the control unit and compares this status information with the target information. If, within a preset execution time, the deviation between the status information and the target information (such as angle difference, position distance, or opening / closing degree difference) is less than or equal to a preset deviation threshold, it indicates that the target part has reached the expected state. The control unit then determines that the target task is completed and switches the task state machine to the idle state to execute the next task.

[0085] If the deviation between the status information and the target information is always greater than the preset deviation threshold within the preset execution time, it indicates that the task execution has timed out or an error has occurred (such as joint jamming or communication interruption causing the target to be unreachable). The target task execution is determined to have failed, and the state of the task state machine is switched to the error state.

[0086] In this embodiment, by making dual judgments on execution time and deviation, it is possible to accurately distinguish between successful and failed tasks, avoiding misjudgments or blocking the task queue due to long delays, thus improving the accuracy of task execution monitoring.

[0087] In some embodiments, the target robot is configured with multiple data buffers, and after receiving the state information of the target part fed back by the control unit during the movement of the target part, the method further includes: The state information is written into the data buffer pointed to by the first atomic pointer corresponding to the write operation; In response to a status information read operation, the status information is read from the data buffer pointed to by the second atomic pointer corresponding to the read operation; After the state information write operation is completed, the data buffers pointed to by the first atomic pointer and the second atomic pointer are swapped.

[0088] Specifically, to efficiently and safely update and access the state information of the target part (such as the actual angle, velocity, and torque of the joint, or the opening and closing degree and gripping force of the gripper) in a multi-threaded environment, and to avoid the performance overhead and deadlock risk of using mutex locks, this embodiment adopts a lock-free double-buffering mechanism. Two independent data buffers (e.g., buffer A and buffer B) are pre-allocated, each capable of storing complete target part state information. Simultaneously, two atomic pointers are maintained: a first atomic pointer (write pointer) and a second atomic pointer (read pointer). An atomic pointer is a pointer variable whose read and write operations are atomic (i.e., cannot be interrupted by other threads).

[0089] Initially, the write pointer points to one buffer (e.g., buffer A), and the read pointer points to the other. When the control unit receives status information from the target location from the underlying control unit, a write operation is performed: the received status information is written to the data buffer (e.g., buffer A) currently pointed to by the first atomic pointer (write pointer). During the write process, read operations can still read the previously received status information from the buffer (e.g., buffer B) pointed to by the second atomic pointer (read pointer), and the two operations do not interfere with each other. After a complete status information write operation is completed, a pointer swap operation is performed: the first atomic pointer and the second atomic pointer are atomically swapped. After the swap, the first atomic pointer (write pointer) points to the buffer that the second atomic pointer previously pointed to (i.e., buffer B), and the second atomic pointer (read pointer) points to the buffer that was just written to (i.e., buffer A). In this way, subsequent read operations can access the latest written status information through the second atomic pointer (read pointer), while new write operations use the other buffer (buffer B) and will not overwrite the data being read. No mutex lock is needed throughout the entire process; all pointer operations are completed atomically.

[0090] In this embodiment, a lock-free double buffering scheme allows the communication thread (responsible for receiving and writing status information) and the upper-level task thread (responsible for reading status information and making task judgments) to execute concurrently. This ensures data consistency and avoids lock contention, thereby improving real-time performance in high-frequency status update scenarios.

[0091] In some embodiments, multiple parts of the target robot are respectively provided with atomic variables, which are used to store the remote control status data of the corresponding parts; After receiving the status information of the target part fed back by the control unit during the movement of the target part, the method further includes: Obtain remote control status data from the status information; Based on the acquired remote control status data, update the values ​​of the atomic variables in the corresponding parts; Read the values ​​of the atomic variables of the target location to determine whether the target location is in a remote control enabled state.

[0092] Specifically, different body parts of the target robot (e.g., left arm, right arm, torso) independently support switching between telecontrol and planning modes. Therefore, it is necessary to maintain a telecontrol enable status identifier for each part. To safely and efficiently read and update these identifiers in a multi-threaded environment without introducing the overhead of mutex locks, this embodiment sets an atomic variable for each part. An atomic variable is a special type of variable whose read, write, and modification operations are atomic (i.e., cannot be interrupted by other threads), ensuring data consistency during concurrent access by multiple threads.

[0093] Each part's atomic variable stores its teleoperation status data. When the control terminal receives the target part's status information through the first communication port, the data packet contains the current teleoperation enable flag for that part. The teleoperation status data is parsed from the received status information, and then the value of the corresponding part's atomic variable is updated based on this data (e.g., setting the atomic variable for the left arm to `true` or `false`). Subsequently, when the task state machine needs to check whether a target part is in a teleoperation enabled state (e.g., performing a conflict check before task execution), it can read the current value of the atomic variable corresponding to that target part to quickly determine its teleoperation enabled state.

[0094] In this embodiment, by using atomic variables to store remote control status data, the communication thread (responsible for receiving status information and updating atomic variables) and the task thread (responsible for reading atomic variables to determine remote control status) can access these variables concurrently without locking. This ensures the real-time performance and accuracy of remote control status information while avoiding performance loss caused by lock contention.

[0095] like Figure 2 The diagram shown is an architectural schematic of the embodied intelligent robot control system provided in an exemplary embodiment of this disclosure. This embodied intelligent robot control system adopts a layered architecture design, including a hardware communication and data model layer, a controller core layer, a kinematics and robot model layer, and a task orchestration and state machine layer. Simultaneously, the embodied intelligent robot control system interacts with the upper-layer application / host computer (which issues tasks via ZeroMQ commands and Jason task files) and the robot hardware (telescopic / planning mode control panels for the arms, torso, grippers, and chassis).

[0096] The hardware communication and data model layer communicates with the robot hardware. This layer defines a unified data model through `gino_motion_driver.hpp`, including `RobotJointMsg` (a robot joint message structure encapsulating data for a single joint), `RobotJointInfo` (a robot joint information structure encapsulating the state set of all joints), and the `TeleopSwitch` structure (used to represent telecontrol mode switching commands). Using the `gino_protobuf_converter` module, these structures can be converted to and from the Protobuf (Protocol Buffers, a cross-platform, language-independent data serialization protocol) format, facilitating interfacing with other processes or network services. `GinoMotionCommunicator` handles UDP (User Datagram Protocol) transmission and reception: on one hand, it sends control commands and receives status information feedback from the control unit (including actual joint angles, speeds, torques, telecontrol enable flags, etc.) through the first communication port; on the other hand, it sends telecontrol mode switching commands through the second communication port (an independent UDP port `teleop_mode_port_`), separate from the control command channel, ensuring the real-time performance and reliability of the switching commands. In addition, this layer manages ZeroMQ Sockets (managed by the upper-layer GinoZmq) for receiving remote control commands. Through this hardware communication and data model layer, upper-layer modules do not need to worry about the underlying communication details and hardware differences, and can use a unified data interface to read and write status information and issue control commands.

[0097] The controller core layer is the control center of the embodied intelligent robot control system. Centered on GinoControllerBase (the controller base class, defining the robot control interface and general logic), it maintains communication links and double-buffered joint state information. The interfaces provided by this layer include: switchTeleop() (telescopic switching interface, used to switch the telescopic enable states of the left arm, right arm, and torso), GinoKinematics (forward and inverse kinematics calculations, calling functions from the kinematics and robot model layer), and GinoUtils (used to read TOML configuration files and load robot parameters, joint limits, communication ports, and other configurations). To achieve thread safety and lock-free access under high-frequency state updates, the controller core layer adopts a lock-free double-buffered design: maintaining two data buffers (buffer_a_ and buffer_b_) and two atomic pointers (read_buffer_ and write_buffer_). The communication thread writes the received state information to the buffer pointed to by write_buffer_, and the upper-layer reading thread obtains the latest state information through read_buffer_. After each update, the two pointers are atomically swapped, thus avoiding the use of mutex locks, reducing performance overhead and the risk of deadlock.

[0098] The core layer of the controller also maintains teleop_enabled_[3] (three atomic variables, corresponding to the teleoperation enable states of the left arm, right arm, and torso respectively), and maintains the real-time accuracy of the state information through the "update teleop_enabled_[3]" process (parsing the teleoperation flag from the RobotJointInfo fed back by the hardware communication layer and updating it atomically). The core layer of the controller also provides the upper layer with a "joint state / motion state query" interface, which allows the task orchestration layer to obtain the current joint angle, speed and other state information. In addition, this layer is also responsible for hardware adaptation work such as joint sequence mapping (mapping the logical joint number to the physical channel corresponding to the hardware driver board), joint limit verification (checking whether the target angle exceeds the mechanical limit), and joint symbol mapping (handling the differences in the motion direction definition of different joints), providing a unified "robot perspective" interface for the upper layer.

[0099] The kinematics and robot model layer constructs three independent kinematic chains—left arm, right arm, and torso—based on KDL (Orocos Kinematics and Dynamics Library, a kinematics and dynamics computation library) and URDF (Unified Robot Description Format, an XML format for describing robot geometry and kinematics models). The GinoKinematics module provides interfaces for forward kinematics (calculating the end effector's pose based on joint angles) and inverse kinematics (solving joint angles from the desired end effector pose). The inverse kinematics interface supports specifying or not specifying a target coordinate system and allows using current joint angles as initial values ​​to optimize convergence speed and stability. This layer maintains the internal states of the current 20 joint angles (obtained from the controller core layer), providing reasonable initial values ​​for repeated solutions, thereby improving the success rate and efficiency of inverse kinematics solutions. Through this layer, the upper task orchestration layer can issue end effector pose control commands without needing to concern itself with specific joint angle conversions, reducing the complexity of task programming.

[0100] The task orchestration and state machine layer is responsible for task reception, parsing, scheduling, and state management. This layer contains two main sub-modules: a JSON task parsing and transformation module (handling the parsing and transformation of JSON task files) and GinoZmq (a ZeroMQ communication management module responsible for receiving remote control commands). Specifically, this layer provides two types of task acquisition methods: a file-driven method, which monitors JSON (JavaScript Object Notation) task files in a specified directory via the fileScanLoop() thread, parses single task objects, task arrays, or structures containing loop blocks (a loop block defines the task array and the number of repetitions, which can be expanded into multiple tasks), converts them into internal tasks, and adds them to the task queue; and a network-driven method, which receives ZeroMQ commands or StateMachineCommands (state machine commands) from the upper-layer application / host computer via ZeroMQ, receives them via GinoZmq, converts them into internal tasks, and adds them to the queue. This layer supports various task types, including joint space motion, Cartesian space motion, pose shift motion, dexterous hand control, three-finger gripper control, chassis movement, offline trajectory execution, remote control mode switching, and waiting. Before executing a task, the task orchestration layer will "check whether the task conflicts with the remote control mode" - that is, query the teleop_enabled_[3] status of the corresponding part in the controller core layer. If the target part is in the remote control enabled state, the task enters the waiting state; otherwise, it is executed normally. For chassis movement tasks, this layer sends the movement command to the hardware by calling MatriceChassisBridge (chassis bridge, which depends on the lib gino_matrix_bridge static library). During the execution of the task, this layer monitors the motion completion conditions and timeout conditions based on the joint status information and time monitoring feedback from the controller core layer, and completes the state switching through the event-driven state machine (supporting idle, execution, waiting, error, pause and other states).

[0101] Through the collaborative operation of the above four-layer architecture, this embodied intelligent robot control system achieves full-body motion control of the robot, which can be an embodied intelligent robot. The loose coupling and high cohesion between the layers ensure real-time communication and high-performance state management, while also providing flexible task orchestration and remote operation / planning mode switching capabilities. It can be widely used in industrial assembly, service robots, scientific research experiments and other scenarios.

[0102] like Figure 3 The diagram shown is another flowchart illustrating an exemplary embodiment of the embodied intelligent robot control method provided in this disclosure. The embodied intelligent robot control method includes: The host computer / user (including scripts, UI interfaces, test programs, etc.) sends tasks to the embodied intelligent robot control system in two ways: one is a JSON file (e.g., a script file containing task sequences), and the other is ZeroMQ commands (control instructions sent in real time over the network, which may include the TELEOP_SWITCH task for switching telecontrol modes). These tasks first enter the task input layer, which is responsible for receiving, parsing, and verifying the tasks. Before task execution, the telecontrol status needs to be queried, that is, the telecontrol enable status of the left arm, right arm, torso, etc., needs to be obtained from the controller core layer (GinoControllerBase). The query result is used to determine whether the task can be executed immediately: if the target part is not telecontrolled, the normal execution process is entered; otherwise, the task waits or reports an error. At the same time, the telecontrol status is updated according to changes in the telecontrol status to keep the status information synchronized.

[0103] During the task execution phase, the tasks are processed according to their types: For ordinary motion tasks (such as joint space motion and Cartesian space motion), the kinematics layer (GinoKinematics, which performs forward and inverse kinematics calculations based on the URDF model and KDL library) is called to convert the end-effector pose into joint angles and generate joint control commands; For telecontrol switching tasks (TELEOP_SWITCH), the switchTeleop() interface of the controller core layer is called to generate telecontrol switching commands. These commands do not go through the kinematics layer but are sent directly to the communication layer.

[0104] The controller core layer (GinoControllerBase) is responsible for maintaining the teleoperation state management (teleop_enabled_[3]) and providing the switchTeleop() interface. It receives query requests from the task input layer and returns the current teleoperation enabled state; at the same time, it receives teleoperation switching tasks and updates the internal state.

[0105] The communication layer (GinoMotionCommunicator) is responsible for sending control commands to the actuator via the UDP protocol. The communication layer distinguishes between two types of commands: UDP joint control, used to send control instructions such as joint angle and speed, and to receive joint status feedback (including the teleop_enable flag), which uses the first communication port; and UDP remote control switching, used to send remote control mode switching commands, using the second communication port (a separate UDP port) to ensure the real-time nature of the switching commands and prevent congestion in the joint control channel.

[0106] The MatrixChassisBridge layer is responsible for handling chassis movement commands. When a task involves chassis movement, the movement commands (such as speed, direction, and distance) are converted into chassis control protocols through this bridging layer and sent to the moving chassis for execution.

[0107] Ultimately, all control commands reach the actuators: the arms, torso, grippers (supporting remote control / planning mode switching), and the moving chassis. During movement, the actuators feed back status information (including actual joint angles, speeds, remote control enable flags, etc.) through the communication layer. This status information is used to update the remote control status of the controller core layer and to determine the conditions for task completion.

[0108] This embodied intelligent robot control method realizes full-link control from user task input, remote operation status check, kinematic solution, command issuance to the underlying actuator, and supports switching between remote operation mode and planning mode.

[0109] The embodied intelligent robot control method and control system provided in this application do not rely on the ROS framework for their core functions and can be directly deployed in non-ROS environments, thereby reducing system complexity and deployment costs and improving portability. Regarding real-time performance, UDP protocol is used for communication, avoiding the transmission delay of ROS middleware. A lock-free double-buffered design is used to maintain the state information of various robot parts, reducing lock contention and improving the performance of multi-threaded concurrent access. In terms of modular design, a layered architecture clarifies the responsibilities of each layer and unifies the interfaces, facilitating expansion and maintenance. It also supports independent compilation into multiple static libraries, which can be selectively linked as needed. Seamless collaboration between telecontrol and planning is achieved: it supports separate telecontrol and planning modes for the left arm, right arm, and torso. The system features real-time switching between control modes. The task state machine automatically checks the remote control status before task execution to avoid conflicts, achieving safe coexistence and smooth transition between the two control modes. The task orchestration mechanism is flexible, supporting various task types, task sequences, loop execution, and conditional judgments based on the task state machine. It provides both JSON file-driven and ZeroMQ network-driven methods for easy system integration and functional expansion. In terms of communication performance, the efficient communication mechanism based on UDP and ZeroMQ can meet the needs of high-frequency control (such as 100Hz offline trajectory execution) and real-time status feedback. Kinematic support is comprehensive, with KDL-based forward and inverse kinematics solutions covering the left arm, right arm, and torso kinematic chains. It also supports specified coordinate systems and initial value optimization, meeting the requirements of complex motion planning. Furthermore, the embodied intelligent robot control system uses TOML format configuration files, supports runtime configuration, and new task types can be added by extending the task type enumeration and corresponding execution logic without modifying the underlying architecture, demonstrating excellent configurability and scalability.

[0110] like Figure 4 The diagram shown is a structural schematic of an embodied intelligent robot control device 40 provided in an exemplary embodiment of this disclosure. The embodied intelligent robot control device 40 includes: The acquisition module 41 is used to form a task queue corresponding to the target robot based on the tasks for the target robot; Extraction module 42 is used to extract target tasks from the task queue when the target robot is in an idle state; The generation module 43 is used to calculate the execution parameters of the target robot and the target part associated with the target task based on the task information of the target task, and generate control commands based on the execution parameters; The control module 44 is used to control the target part through the control command, and to switch the state of the target robot to an idle state when the target task is completed.

[0111] In some embodiments, the generation module 43 is further configured to: If the target part is not in a remote control enabled state, perform the step of calculating the execution parameters of the target robot and the target part associated with the target task based on the task information of the target task; If the target location is in a remote control enabled state, the target task will be stopped.

[0112] In some embodiments, after switching the state of the task state machine to a waiting state, the generation module 43 is further configured to: If the remote control enable state of the target part is detected to be deactivated, the target task is re-executed, or a new target task is executed.

[0113] In some embodiments, the target location includes a target joint, and the generation module 43 is specifically used for: When the task information indicates that the target task is a first type of motion task, the target parameters of the target part are obtained from the task information and used as the execution parameters of the target part. When the task information indicates that the target task is a second type of motion task, based on the pre-determined kinematic chains associated with robot body parts, the target kinematic chain corresponding to the target part is determined, the state parameters of each joint in the target kinematic chain are obtained, and the target end pose of the target robot is obtained from the task information. Based on the state parameters, the target end pose and the inverse kinematic function, the execution parameters of the target part are calculated.

[0114] In some embodiments, the generation module 43 is further configured to: If the execution parameters are within a preset safety range, the step of generating control instructions based on the execution parameters is executed; If the execution parameters are outside the preset safety range, stop executing the target task, or adjust the execution parameters of the target part to a preset value and continue executing the step of generating control instructions based on the execution parameters.

[0115] In some embodiments, the control module 44 is specifically used for: The control command is sent to the control unit corresponding to the target part through the first communication channel of the first communication port to control the target part; The control module 44 is also used for: The second communication channel of the first communication port receives the status information of the target part fed back by the control unit during the movement of the target part.

[0116] In some embodiments, the embodied intelligent robot control device 40 further includes a switching module (not shown), the switching module being used for: A remote operation mode switching command is sent to the control unit of the target part through the second communication port to switch the control mode of the target part to the remote operation mode. If the control unit is in a state of responding to the control command to control the target part when it receives the remote operation mode switching command, the execution of the control command is interrupted and the control mode of the target part is switched to the remote operation mode.

[0117] In some embodiments, after receiving the state information of the target part fed back by the control unit during the movement of the target part, the control module 44 is further configured to: Obtain the target information corresponding to the target location from the task information; If the deviation between the status information and the target information is less than or equal to a preset threshold within a preset execution time, the target task is determined to be completed. If the deviation between the status information and the target information exceeds a preset threshold within a preset execution time, the target task is determined to have failed.

[0118] In some embodiments, the embodied intelligent robot control device 40 further includes a read / write module (not shown). The target robot is configured with multiple data buffers. After receiving the status information of the target part fed back by the control unit during the movement of the target part, the read / write module is used to: The state information is written into the data buffer pointed to by the first atomic pointer corresponding to the write operation; In response to a status information read operation, the status information is read from the data buffer pointed to by the second atomic pointer corresponding to the read operation; After the state information write operation is completed, the data buffers pointed to by the first atomic pointer and the second atomic pointer are swapped.

[0119] In some embodiments, multiple parts of the target robot are respectively provided with atomic variables, which are used to store the remote control status data of the corresponding parts; After receiving the status information of the target part fed back by the control unit during the movement of the target part, the control module 44 is further configured to: Obtain remote control status data from the status information; Based on the acquired remote control status data, update the values ​​of the atomic variables in the corresponding parts; Read the values ​​of the atomic variables of the target location to determine whether the target location is in a remote control enabled state.

[0120] In some embodiments, the acquisition module 41 is specifically used for: If a new task file is detected in a specified storage address, the task file is parsed to obtain the task for the target robot. And / or, receive task instructions for the target robot via network communication, and parse the task instructions to obtain the task for the target robot.

[0121] In some embodiments, the embodied intelligent robot control device 40 further includes a maintenance module (not shown), which is used to maintain the state of the target robot through a task state machine, the state including at least an idle state, an executing state, a waiting state, an error state, and a paused state.

[0122] The embodied intelligent robot control device 40 provided in this application embodiment can manage multiple tasks in an orderly manner by adding tasks for the target robot to a task queue, thus avoiding chaos in the task execution order; when the target robot is in an idle state, the target task is extracted from the queue, which can prevent instruction conflicts caused by the simultaneous execution of multiple tasks; the execution parameters of the relevant target parts of the target robot are calculated based on the task information of the target task and control instructions are generated, so that the control instructions are precisely matched with the task requirements; after the target task is completed, the state of the target robot is switched back to the idle state, which can enable the subsequent tasks in the task queue to be processed in sequence, thereby improving the accuracy and reliability of robot control as a whole.

[0123] like Figure 5The diagram shown is a schematic representation of the internal structure of an electronic device provided in an exemplary embodiment of this disclosure. The electronic device includes a processor, a memory, an input / output interface, a communication interface, a display unit, and an input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements an embodied intelligent robot control method. The display unit of the electronic device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the electronic device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the electronic device, or external keyboards, touchpads, or mice, etc.

[0124] Those skilled in the art will understand that Figure 5 The structure shown is only a block diagram of a part of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0125] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0126] Since the computer program stored in the computer-readable storage medium can execute any of the embodied intelligent robot control methods provided in the embodiments of this application, the beneficial effects that any of the embodied intelligent robot control methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0127] Based on the same inventive concept, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0128] It should be noted that, in the data processing stage, the technical solution of this application has strictly limited the scope of data collection to the minimum necessary to achieve the technical objectives, preventing the acquisition of irrelevant information. For any user information to be collected, the data subject will be clearly informed and their consent obtained. Furthermore, technologies such as encrypted storage and access control are employed to strengthen data security and ensure the security and compliance of the entire data processing process. The technical model and decision-making mechanism are based on objective technical parameters and do not introduce unnecessary parameters such as gender or age that may lead to discrimination, resolutely eliminating algorithmic discrimination and upholding public order and good morals. In addition, the specification fully describes the technical implementation methods, application scenarios, and compliance protection details. The claims are consistent with the content of the specification, key compliance designs are clear and verifiable, and the overall technical design is guided by the protection of public interests and adherence to social ethics, without any circumstances that harm public interests or violate public order and good morals.

[0129] Any reference to memory, database, or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0130] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0131] In the above embodiments of the embodied intelligent robot control device, computer-readable storage medium, electronic device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes and beneficial effects of the embodied intelligent robot control device, computer-readable storage medium, computer program product, electronic device, and their corresponding units described above can be referred to the description of the embodied intelligent robot control method in the above embodiments, and will not be repeated here.

[0132] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0133] The foregoing has provided a detailed description of the embodied intelligent robot control method, embodied intelligent robot control device, electronic device, computer-readable storage medium, and computer program product provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for controlling an embodied intelligent robot, characterized in that, Includes the following steps: Based on the tasks assigned to the target robot, a task queue corresponding to the target robot is formed; When the target robot is in an idle state, the target task is extracted from the task queue; Based on the task information of the target task, calculate the execution parameters of the target robot and the target part associated with the target task, and generate control commands based on the execution parameters; The target part is controlled by the control command, and the target robot is switched to an idle state when the target task is completed.

2. The method according to claim 1, characterized in that, The method further includes: If the target part is not in a remote control enabled state, perform the step of calculating the execution parameters of the target robot and the target part associated with the target task based on the task information of the target task; If the target location is in a remote control enabled state, the target task will be stopped.

3. The method according to claim 2, characterized in that, After the target task is stopped, the method further includes: If the remote control enable state of the target part is detected to be deactivated, the target task is re-executed, or a new target task is executed.

4. The method according to claim 1, characterized in that, The target part includes a target joint. The step of calculating the execution parameters of the target robot associated with the target part based on the task information of the target task includes: When the task information indicates that the target task is a first type of motion task, the target parameters of the target part are obtained from the task information and used as the execution parameters of the target part. When the task information indicates that the target task is a second type of motion task, based on the pre-determined kinematic chains associated with robot body parts, the target kinematic chain corresponding to the target part is determined, the state parameters of each joint in the target kinematic chain are obtained, and the target end pose of the target robot is obtained from the task information. Based on the state parameters, the target end pose and the inverse kinematic function, the execution parameters of the target part are calculated.

5. The method according to claim 1, characterized in that, The method further includes: If the execution parameters are within a preset safety range, the step of generating control instructions based on the execution parameters is executed; If the execution parameters are outside the preset safety range, stop executing the target task, or adjust the execution parameters of the target part to a preset value and continue executing the step of generating control instructions based on the execution parameters.

6. The method according to claim 1, characterized in that, The control of the target part via the control command includes: The control command is sent to the control unit corresponding to the target part through the first communication channel of the first communication port to control the target part; The method further includes: The second communication channel of the first communication port receives the status information of the target part fed back by the control unit during the movement of the target part.

7. The method according to claim 6, characterized in that, The method further includes: A remote operation mode switching command is sent to the control unit of the target part through the second communication port to switch the control mode of the target part to the remote operation mode. If the control unit is in a state of responding to the control command to control the target part when it receives the remote operation mode switching command, the execution of the control command is interrupted and the control mode of the target part is switched to the remote operation mode.

8. The method according to claim 6, characterized in that, After receiving the status information of the target part fed back by the control unit during the movement of the target part, the method further includes: Obtain the target information corresponding to the target location from the task information; If the deviation between the status information and the target information is less than or equal to a preset threshold within a preset execution time, the target task is determined to be completed. If the deviation between the status information and the target information exceeds a preset threshold within a preset execution time, the target task is determined to have failed.

9. The method according to claim 6, characterized in that, The target robot is configured with multiple data buffers. After receiving the state information of the target part fed back by the control unit during the movement of the target part, the method further includes: The state information is written into the data buffer pointed to by the first atomic pointer corresponding to the write operation; In response to a status information read operation, the status information is read from the data buffer pointed to by the second atomic pointer corresponding to the read operation; After the state information write operation is completed, the data buffers pointed to by the first atomic pointer and the second atomic pointer are swapped.

10. The method according to claim 6, characterized in that, The target robot has atomic variables set for each of its multiple parts, and the atomic variables are used to store the remote control status data of the corresponding parts. After receiving the status information of the target part fed back by the control unit during the movement of the target part, the method further includes: Obtain remote control status data from the status information; Based on the acquired remote control status data, update the values ​​of the atomic variables in the corresponding parts; Read the values ​​of the atomic variables of the target location to determine whether the target location is in a remote control enabled state.

11. The method according to any one of claims 1-10, characterized in that, The process of acquiring the task for the target robot includes: If a new task file is detected in a specified storage address, the task file is parsed to obtain the task for the target robot. And / or, receive task instructions for the target robot via network communication, and parse the task instructions to obtain the task for the target robot.

12. The method according to any one of claims 1-10, characterized in that, The method further includes: The state of the target robot is maintained by a task state machine, and the state includes at least an idle state, an executing state, a waiting state, an error state, and a paused state.

13. An electronic device, characterized in that, The system includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to perform the steps of the embodied intelligent robot control method as described in any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the embodied intelligent robot control method as described in any one of claims 1 to 12.

15. A computer program product, characterized in that, The computer program product includes a computer program or instructions, which are executed by a processor using the steps of the embodied intelligent robot control method as described in any one of claims 1 to 12.

Images