Unified access and control method, system, storage medium and related equipment of body-aware robot

Abstract

The application provides a unified access, control method, system, storage medium and related equipment of a body intelligent robot, by introducing a standardized abstract interface and an adapter code generation mechanism driven by a large language model, automatic adaptation of different manufacturers and different types of robot native interfaces is realized, and the development cost and cycle of upper application connection to multiple robots are greatly reduced. Specifically, the unified access method of the application converts the native interface document of the target robot into an adapter code conforming to the standardized abstract interface through a large language model, loads and registers to form a digital robot, and provides a unified control entrance for the upper application, thereby effectively solving the problems of robot interface fragmentation and inconsistent action semantics in the prior art, and providing a solid technical support for the large-scale application of the body intelligent robot.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a unified access and control method, system, storage medium and related equipment for an embodied intelligent robot. Background Technology

[0002] In the field of embodied intelligent robots, robots designed by different manufacturers or R&D teams often employ differentiated hardware architectures and software interface systems. For example, industrial collaborative robots may rely on a topic communication interface based on ROS (Robot Operating System) to transmit joint angle commands, service robots may receive natural language control requests via HTTP API, and special-purpose robots may even use custom serial communication protocols to achieve motion control. This "interface fragmentation" problem means that if upper-layer applications need to interface with multiple robots, they must develop independent adaptation code for each robot's native interface, which not only increases development costs and time but also significantly increases the difficulty of system maintenance.

[0003] Meanwhile, existing robot control solutions lack a unified standard for motion abstraction. Different robots define basic actions such as "grasping" and "movement" differently: some robots break down "grasping" into three sub-steps: "approaching the target - closing the gripper - lifting the object," while others encapsulate it into a single composite motion command. This inconsistency in motion semantics makes cross-robot task scheduling and collaborative operations difficult. When upper-level applications need to schedule multiple robots to complete the same complex task, it is impossible to directly describe the motion requirements through a unified command. Instead, customized programming must be performed for the motion logic of each robot, severely limiting the scalability and versatility of embodied intelligent robot systems. Summary of the Invention

[0004] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the high development cost, long development cycle, and poor scalability and versatility of existing embodied intelligent robots.

[0005] This application provides a unified access method for embodied intelligent robots, the method being applied to a general control system, including:

[0006] Obtain the target robot's native API documentation;

[0007] The native interface document, the standardized abstract interface of the predefined robot parts, and the predefined standard meta-action library information are input into the large language model, and executable adapter code that conforms to the standardized abstract interface is generated through the large language model.

[0008] The executable adapter code is loaded and registered into a preset robot management module to form a digital robot corresponding to the target robot;

[0009] The digital robot is used to provide external applications with unified control over the target robot through its standardized abstract interface.

[0010] Optionally, the standardized abstract interface of the predefined robot component is defined according to a multi-layered architecture, including:

[0011] The component base class defines the common basic operation methods that all robot components must implement;

[0012] An abstract class for vertical components, which inherits from the base class of components, defines special functional methods for components of a specific category;

[0013] The executable adapter code is implemented by a concrete adapter class that inherits from the abstract class of the vertical component.

[0014] Optionally, generating executable adapter code conforming to the standardized abstract interface through the large language model includes:

[0015] Based on the syntactic constraints of the standardized abstract interface and the semantic constraints of the standard meta-action library information, the large language model is guided to extract the interface implementations of each robot component from the native interface document and generate the corresponding executable adapter code.

[0016] Optionally, the syntactic constraints based on the standardized abstract interface and the semantic constraints based on the standard meta-action library information guide the large language model to extract the interface implementations of each robot component from the native interface document and generate corresponding executable adapter code, including:

[0017] Based on the standardized abstract interface, determine the vertical component abstract class corresponding to each robot component of the target robot;

[0018] Based on the type of each robot component, the corresponding standard meta-action definitions are selected from the standard meta-action library information;

[0019] Based on the descriptions of each robot component in the native interface document, the definition of the corresponding vertical component abstract class, and the selected standard meta-action definitions, prompt words are constructed and input into the large language model;

[0020] Receive the source code of concrete adapter classes that are inherited from the abstract classes of each vertical component and are output by the large language model in response to the prompt word, and use the source code of each concrete adapter class as executable adapter code.

[0021] Optionally, loading and registering the executable adapter code into a preset robot management module includes:

[0022] Static syntax checking and key API pattern verification are performed on the executable adapter code;

[0023] After the executable adapter code passes verification, the executable adapter code and the corresponding configuration file are packaged into an adapter package;

[0024] During system runtime, the adapter package is loaded into memory using dynamic module loading technology, and the initialization function in the adapter package is called to create an adapter instance, which is then registered to the preset robot management module.

[0025] This application also provides a unified control method for an embodied intelligent robot, the method being applied to a general control system integrating at least one digital robot, wherein the digital robot is generated and registered using the unified access method described in any of the above embodiments, the method comprising:

[0026] Receive task instructions from upper-layer applications;

[0027] The task instructions are decomposed into a set of ordered, atomized standard meta-action sequences;

[0028] For each standard meta-action in the standard meta-action sequence, the standardized abstract interface exposed by the digital robot executing the standard meta-action is invoked, and a standardized instruction conforming to the standard abstract interface specification is passed in;

[0029] The standardized instructions are mapped to the corresponding native control instructions of the physical robot via the component adapter corresponding to the digital robot and then sent for execution.

[0030] Optionally, the standardized abstract interface exposed by the digital robot that invokes the standard meta-action includes:

[0031] Based on the type and parameters of the standard meta-action, and the metadata of all connected digital robots stored in the preset robot management module, select the digital robot to execute the standard action.

[0032] Invoke the standardized abstract interface exposed by the digital robot that performs the standard meta-action.

[0033] Optionally, the input of standardized instructions conforming to the standardized abstract interface specification includes:

[0034] Obtain the real-time status of the physical robot corresponding to the digital robot performing the standardized action;

[0035] Based on the real-time status and the type and parameters of the standard meta-action, a continuous sequence of trajectory points is generated using a trajectory planning algorithm;

[0036] The trajectory point sequence is encapsulated into standardized instructions that conform to the standardized abstract interface specification, and then passed into the standardized abstract interface.

[0037] Optionally, the method further includes:

[0038] The component adapter receives the status data returned by the controller of the physical robot after executing the native control command, converts the status data into a predefined standardized status format, and then updates the status field of the digital robot.

[0039] This application also provides a general control system, including:

[0040] The document acquisition module is used to acquire the native interface documents of the target robot;

[0041] The code generation module is used to input the native interface document, the standardized abstract interface of the predefined robot parts, and the predefined standard meta-action library information into the large language model, and generate executable adapter code that conforms to the standardized abstract interface through the large language model;

[0042] The loading and registration module is used to load and register the executable adapter code into a preset robot management module to form a digital robot corresponding to the target robot;

[0043] The digital robot is used to provide external applications with unified control over the target robot through its standardized abstract interface.

[0044] This application also provides a general control system, including:

[0045] The instruction receiving module is used to receive task instructions issued by the upper-layer application;

[0046] The task decomposition module is used to decompose the task instructions into a set of ordered, atomic standard meta-action sequences;

[0047] The interface calling module is used to call the standardized abstract interface exposed by the digital robot that executes the standard meta-action for each standard meta-action in the standard meta-action sequence, and pass in standardized instructions that conform to the standard abstract interface specification.

[0048] The standardized instructions are mapped to the corresponding native control instructions of the physical robot via the component adapter corresponding to the digital robot and then sent for execution.

[0049] This application also provides a computer-readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the unified access method for an embodied intelligent robot as described in any of the above embodiments, and / or the steps of the unified control method for an embodied intelligent robot as described in any of the above embodiments.

[0050] This application also provides a computer device, including: one or more processors, and memory;

[0051] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the unified access method for an embodied intelligent robot as described in any of the above embodiments, and / or the steps of the unified control method for an embodied intelligent robot as described in any of the above embodiments.

[0052] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0053] The unified access and control method, system, storage medium, and related equipment for embodied intelligent robots provided in this application achieve automated adaptation to the native interfaces of robots from different manufacturers and of different types by introducing a standardized abstract interface and an adapter code generation mechanism driven by a large language model. This significantly reduces the development cost and cycle of upper-layer applications connecting to multiple robots. Specifically, the unified access method of this application converts the native interface document of the target robot into adapter code that conforms to the standardized abstract interface through a large language model. After loading and registration, it forms a digital robot, providing a unified control entry point for upper-layer applications. This effectively solves the problems of fragmented robot interfaces and inconsistent action semantics in existing technologies, providing solid technical support for the large-scale application of embodied intelligent robots. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0055] Figure 1 A flowchart illustrating a unified access method for an embodied intelligent robot provided in an embodiment of this application;

[0056] Figure 2 This is a schematic diagram of the overall access architecture from L1 to L3 provided in an embodiment of this application;

[0057] Figure 3 A flowchart illustrating a unified control method for an embodied intelligent robot provided in an embodiment of this application;

[0058] Figure 4 This is a schematic diagram of the structure of one of the general control systems provided in the embodiments of this application;

[0059] Figure 5 This is a schematic diagram of another general control system provided in an embodiment of this application;

[0060] Figure 6 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0061] 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.

[0062] To address the technical problems existing in the prior art, this application constructs a middleware abstraction layer centered on a "digital robot" between physical robot hardware and upper-level intelligent applications. This layer uses "component-based" modeling and "dynamic loading" adaptation technology to uniformly map heterogeneous hardware into a standard, programmable control interface, thereby enabling upper-level applications to transparently and in a standardized manner call the underlying hardware.

[0063] This system mainly includes the following software modules, which run in the computer system as processes, services, or libraries, and exchange data and make logical calls through predefined software interfaces (such as API calls, message queues, and shared memory):

[0064] 1. Component adapter generation

[0065] The component adapter generation module, as the core intelligent engine of this invention, bears the important responsibility of automatically converting unstructured and heterogeneous robot native interface documents into executable adapter code that conforms to the unified standard interface defined by the system. It receives the technical documentation (SDK / API manual) of the target robot and can automatically generate a component adapter software package that can be directly loaded and executed by the "runtime dynamic loader module".

[0066] 2. Loading during robot operation

[0067] Task and Action Scheduling Execution Engine: This is the system's central processing unit, a continuously running service process that internally maintains a task queue and state machine. It receives structured task descriptions in JSON or Protocol Buffers format from upper-layer applications (such as the large model planner), and decomposes and schedules them into sequential or parallel meta-action execution sequences based on built-in workflow logic. Its working principle is to dynamically generate a continuous sequence of joint space or Cartesian space trajectory points within a specific time window, conforming to kinematic constraints, based on the scheduled meta-action type and parameters, combined with the real-time state of the target robot (such as pose and joint angles) obtained from the robot management module, using internally pre-built algorithms (such as interpolation algorithms and trajectory planners). This sequence is then encapsulated into motion instructions in a standard format (such as a Float array).

[0068] The robot management module acts as a registry and manager for robot resources. It's a database-driven service (such as SQLite or Redis) that stores metadata (unique ID, capability description, network address, and real-time status) for all connected digital robots. It provides APIs such as register(), deregister(), and getRobotList() for other modules to query and select available robot resources.

[0069] Robot Dynamic Loader Module: This is a component responsible for loading Python modules, and its workflow is as follows:

[0070] A. Discovery: Scan for adapter packages (e.g., robot_adaper_{Vendor}_{Model}.zip) that conform to the naming conventions in the specified directory.

[0071] B. Verification and Loading: The package is unzipped, and the manifest.json configuration file is read to verify its signature and dependencies. Then, the core adapter library files in the package are loaded into memory using operating system APIs (such as dlopen() in Linux and importlib in Python).

[0072] C. Registration: Call the adapter library's initialization function to create an instance of it and register it in the robot management module to complete the "hot-swappable" access of a new model robot.

[0073] 3. Command Sending and Access for "Digital Robot"

[0074] Digital Robot (Virtual Entity): It is not a specific process, but a set of data structures and proxy objects. Each connected physical robot corresponds to a "digital robot" instance in the system. This instance contains the following fields in memory: RobotID (identifier), CapabilityList (capability list, such as ["move", "grab", "6DOF_arm"]), and Status (current status, such as idle, busy, error).

[0075] The external interface of a physical robot: This is an abstract base class or interface. In object-oriented programming, it defines a standard set of methods that all robots must implement, for example:

[0076] class RobotBaseInterface:

[0077] def connect(self, config: Dict) -> bool: ...

[0078] def disconnect(self) -> bool: ...

[0079] def execute_trajectory(self, traj: List[float]) -> bool: ...

[0080] def get_status(self) -> RobotStatus: ...

[0081] Component base class and component adapter:

[0082] Base class for components: This is a further abstraction of the functional components of the robot. For example, the ArmComponentBase class may define methods such as move_to_pose(pose) and grasp(object_id); the MobileBaseComponentBase class defines methods such as navigate_to(x, y, theta).

[0083] Component adapters are concrete implementation classes for specific robot models. For example, the UR5eArmAdapter class inherits from ArmComponentBase, and its move_to_pose method contains all the code logic for converting standard pose data into UR robot-specific URScript instructions and sending them to the actual UR5e control cabinet via Socket communication.

[0084] 4. Physical robot docking

[0085] Robot hardware: refers to the actual physical robot and its controller.

[0086] Specifically, this application is implemented through the following method:

[0087] In one embodiment, such as Figure 1 As shown, Figure 1 A flowchart illustrating a unified access method for an embodied intelligent robot provided in this application embodiment; this application provides a unified access method for an embodied intelligent robot, the method being applied to a general control system, and may include:

[0088] S110: Obtain the target robot's native interface documentation.

[0089] In this step, when uniformly connecting different types of physical robots, it is first necessary to obtain the target robot's native interface documentation. These documents are usually provided by the robot manufacturer and contain key information such as the robot hardware's communication protocols, control command formats, and data interaction methods.

[0090] For example, the native interface documentation for a collaborative robot brand might detail its communication port number via TCP / IP, command frame structure, and encoding rules for data such as joint angles and end effector positions. Meanwhile, the documentation for a mobile robot model might focus on its ROS (Robot Operating System)-based topic publishing and subscription mechanism, as well as the parameter requirements for navigation commands. The system can acquire native interface documentation by automatically scanning document files (such as PDF, Word, and Markdown formats) in a specified directory or by receiving document packages manually uploaded by the user. For unstructured information within the documentation, such as commands described in natural language, the system can also use text parsing tools for preliminary information extraction, providing foundational data support for subsequent adapter generation.

[0091] S120: Input the native interface documentation, the standardized abstract interface of the predefined robot parts, and the predefined standard meta-motion library information into the large language model, and generate executable adapter code that conforms to the standardized abstract interface through the large language model.

[0092] In this step, after obtaining the target robot's native interface document via S110, this application can input this document, along with the system's predefined standardized abstract interfaces for robot components (such as the method signatures and parameter formats specified by base classes like ArmComponentBase and MobileBaseComponentBase mentioned earlier), and standard meta-action library information covering actions such as "moving to coordinate points," "grasping a specified object," and "adjusting joint angles," into a large language model (such as GPT-4, Claude, or other models with code generation capabilities). Based on its semantic understanding of the native interface document, and combining the constraints of the standardized abstract interfaces with the semantic mapping relationship between standard meta-actions, the large language model can automatically generate executable adapter code.

[0093] For example, if the native interface of the target robot uses the command "MOVE_JOINT(j1,j2,j3,j4,j5,j6,speed)" to control the movement of the robotic arm, and the corresponding method in the standardized abstract interface is "move_to_joint_positions(joint_values: List[float], velocity: float)", the large language model will generate adapter code. This adapter code converts the input parameters of the standardized method (such as the list of joint angles and velocity values) into the format of the native command and implements the logic for sending the native command to the robot controller via network communication (such as Socket or ROS topics). Simultaneously, the code can also include parsing logic for the results returned after the robot executes the command, ensuring that the native state data is converted into a system-recognizable format. The generated adapter code typically exists as a Python module or dynamic link library (such as .so or .dll files), and can be directly loaded and executed by the system's dynamic loader module.

[0094] It should be noted that the standard meta-action library information in this application refers to a set of standardized actions predefined by the system, covering common basic operations of robots. Each meta-action contains a unified semantic description, parameter format, and execution logic constraints. For example, the meta-action "move to Cartesian coordinate point" explicitly specifies that the parameters must include the X / Y / Z axis values ​​of the target coordinates, the posture quaternion, and the motion speed threshold; the meta-action "grasp object" requires parameters such as the object ID and the grasping force range. These meta-actions serve as a "semantic bridge" between upper-layer applications and lower-layer hardware, ensuring that similar operations of robots from different manufacturers can be called uniformly. When generating adapter code, the large language model automatically establishes a mapping relationship between native interface instructions and standard meta-actions. For example, it binds a robot's native "GRASP(force_level)" instruction to the system's "grab_object(force: int)" meta-action, achieving automatic parameter conversion and instruction encapsulation. This allows upper-layer applications to drive the robot to perform corresponding operations simply by calling the standard meta-actions, without needing to pay attention to the differences in instructions of the lower-layer hardware.

[0095] S130: Load and register the executable adapter code into the preset robot management module to form a digital robot corresponding to the target robot.

[0096] In this step, after generating executable adapter code conforming to the standardized abstract interface through the large language model in S120, this application can load and register the executable adapter code into the preset robot management module to form a digital robot corresponding to the target robot. This digital robot is used to provide external applications with unified control capabilities over the target robot through its standardized abstract interface.

[0097] Specifically, the loading process in this application is completed by the robot dynamic loader module. This module scans the adapter code packages in the specified directory, verifies their signatures and dependencies, and then loads the code into memory through Python's importlib module or the operating system's dynamic link library loading interface. Subsequently, the dynamic loader calls the initialization function in the adapter code to create an adapter instance and encapsulates the core information of this instance (such as the robot's unique identifier, supported component types, and a list of standardized interface methods) into the digital robot's metadata, which is then sent to the robot management module for registration. After receiving the registration request, the robot management module stores the digital robot's metadata in the built-in SQLite database and updates the real-time resource list. At this point, the upper-layer application can query the digital robot by calling APIs such as getRobotList() in the robot management module, completing the mapping from the physical robot hardware to the system's virtual abstraction layer.

[0098] After the digital robot is registered, if the upper-layer application needs to send control commands to the physical robot, it does not need to interact directly with the robot's native interface. Instead, it only needs to initiate a request through the standardized interface provided by the "Digital Robot" command sending and access module. For example, when the application needs to control the physical robot's robotic arm to move to a certain Cartesian coordinate point, it can call the digital robot's corresponding "move_to_cartesian_pose(pose: Tuple[float, float, float], orientation: Tuple[float, float, float])" method and pass in the target coordinates and attitude parameters. After receiving the request, the digital robot can pass the parameters to the corresponding component adapter instance. The adapter instance converts the standardized parameters into a native instruction format that the physical robot can recognize, according to the pre-generated conversion logic. If the physical robot supports ROS topic communication, the adapter will encapsulate the coordinate data into a message of type geometry_msgs / PoseStamped and publish it to the specified topic through the ROS node. If the physical robot uses TCP / IP direct communication, the adapter will pack the parameters into a byte stream according to the frame structure of the native protocol (such as start bit, data bit, and check bit) and send it to the specified port of the robot controller through the Socket.

[0099] In the above embodiments, by introducing a standardized abstract interface and a large language model-driven adapter code generation mechanism, automated adaptation to the native interfaces of robots from different manufacturers and of different types is achieved, significantly reducing the development cost and cycle of upper-layer applications connecting to multiple robots. Specifically, the unified access method of this application converts the native interface document of the target robot into adapter code conforming to the standardized abstract interface through a large language model. After loading and registration, a digital robot is formed, providing a unified control entry point for upper-layer applications. This effectively solves the problems of fragmented robot interfaces and inconsistent action semantics in the prior art, providing solid technical support for the large-scale application of embodied intelligent robots.

[0100] In one embodiment, the standardized abstract interface of the predefined robot component, defined according to a multi-layered architecture, may include:

[0101] The component base class defines the common basic operation methods that all robot components must implement.

[0102] The vertical component abstract class, which inherits from the component base class, defines special functional methods for components of a specific category.

[0103] The executable adapter code is implemented by a concrete adapter class that inherits from the abstract class of the vertical component.

[0104] In this embodiment, since the motion execution of all robots on the market is essentially based on individual components of the robot body, such as arms, legs, and cameras, the external interfaces of these components are essentially the same regardless of the robot model. The differences lie in the protocols and interfaces used to connect to different robots. Therefore, based on the above characteristics, this application abstracts the robot's access architecture into three layers, forming an overall access architecture from L1 to L3:

[0105] - L1: PartBase - Defines the interface for generic parts;

[0106] - L2: Base (CameraBase / AsrBase, etc.) - Defines the interface for vertical component categories (such as the camera's take_photo());

[0107] - L3: The concrete implementation class that ultimately connects to a specific robot model - implements the specific communication protocol and interfaces with the hardware SDK.

[0108] Indicatively, such as Figure 2 As shown, Figure 2 This is a schematic diagram of the overall access architecture from L1 to L3 provided in the embodiments of this application; by Figure 2 As can be seen, in this three-layer architecture, from L1 to L2, common connection and control interfaces are designed and implemented, while external interfaces that need to be implemented by L3 are defined. The specific component adapter class (L3) inherits from the corresponding vertical component abstract class (L2, such as CameraBase), and all vertical component abstract classes inherit from the top-level component base class (L1, PartBase), thus ensuring that all adapters implement the necessary methods (connect, execute, etc.) defined by PartBase.

[0109] The standardized interface defined by L1 is as follows:

[0110] class PartBase:

[0111] # Abstract methods that must be implemented

[0112] @abstractmethod

[0113] def connect() -> bool # Connect device

[0114] @abstractmethod

[0115] def is_valid(command) -> bool # Command validation

[0116] @abstractmethod

[0117] def fetch_data() -> List # Data collection

[0118] @abstractmethod

[0119] def register_command(register) # Register command

[0120] @abstractmethod

[0121] def execute(command) -> dict # Command execution

[0122] Furthermore, for each category's vertical component abstract class, the abstract definition of that category's components is further specified to address the specific characteristics of those components. For example, for a camera, the following interface standard can be defined in L2:

[0123] class CameraBase(PartBase):

[0124] # Camera-specific interface

[0125] @abstractmethod

[0126] def open(command) -> bool # Open the camera

[0127] @abstractmethod

[0128] def take_photo(command) -> dict # Take a photo (returns image data)

[0129] @abstractmethod

[0130] def set_mode(command) -> bool # Set the trigger mode

[0131] @abstractmethod

[0132] def close(command) -> None # Turn off the camera

[0133] Based on this definition, L3 only needs to extract the content implementing the standard interfaces specified by L1 and L2 from the SDK documentation of a specific robot model using a large model. Meanwhile, for some universally applicable component models, such as cameras (e.g., ROS2-based fisheye cameras, 2D cameras), the L3 implementation for that type of camera will be directly implemented. In this way, for a specific robot model, as long as its components belong to that model, the built-in L3 implementation can be directly reused without needing to extract interfaces from the SDK.

[0134] In one embodiment, generating executable adapter code conforming to the standardized abstract interface through the large language model in step S120 may include:

[0135] S121: Based on the syntactic constraints of the standardized abstract interface and the semantic constraints of the standard meta-action library information, guide the large language model to extract the interface implementations of each robot component from the native interface document and generate the corresponding executable adapter code.

[0136] In this embodiment, following the three-layer access technology architecture described above, what is essentially extracted from the robot SDK documentation is the interface implementation of each component in L3. For different robots, due to differences in robot SDK interfaces and communication protocols, semantic ambiguity may still exist. To further constrain this, this application defines a standard meta-action library for each type of component. This is a structured skill knowledge base that can be stored in a YAML file or a database. The standard meta-action library contains structured information such as meta-action name, action description, input parameter requirements, and output result format. For example, for the "joint space movement" meta-action of a robotic arm, its input parameters are clearly defined as a list of joint angles (length matching the robotic arm's degrees of freedom) and movement speed (unit: rad / s), and the output result is the action execution status (success / failure) and current joint angle feedback.

[0137] Before inputting the native interface documentation into the large language model, the system first converts the constraint information of the standard meta-action library into natural language prompts. For example, "Please identify the native interface corresponding to the 'joint space movement' meta-action from the native interface documentation, ensure that its input parameters include a list of joint angles and movement speed, and its output parameters include execution status and joint angle feedback, and generate adapter code that conforms to the signature of the take_photo method in the CameraBase class." When generating code, the large language model simultaneously refers to the syntax rules of the standardized abstract interface (such as method name and parameter type) and the semantic rules of the standard meta-action library (such as the functional boundaries of the action and the physical meaning of the parameters) to avoid semantic biases such as "incorrectly mapping the 'adjust camera exposure' interface to the 'take a picture' meta-action."

[0138] In addition, the system can perform static syntax checks (such as using the pylint tool to verify the syntax correctness of Python code) and semantic consistency checks (such as comparing whether the parameters of the native interfaces called in the code match the parameter requirements of the standard meta-action library). If a deviation is found, the verification results are fed back to the large language model for secondary correction until the generated code fully meets the constraints.

[0139] In one embodiment, S121, based on the syntactic constraints of the standardized abstract interface and the semantic constraints of the standard meta-action library information, guides the large language model to extract the interface implementations of each robot component from the native interface document and generate corresponding executable adapter code, which may include:

[0140] S1211: Based on the standardized abstract interface, determine the vertical component abstract class corresponding to each robot component of the target robot.

[0141] S1212: Based on the type of each robot component, select the corresponding standard meta-motion definition from the standard meta-motion library information.

[0142] S1213: Based on the descriptions of each robot component in the native interface document, the definition of the corresponding vertical component abstract class, and the selected standard meta-action definitions, construct prompt words and input them into the large language model.

[0143] S1214: Receive the source code of the concrete adapter class, which is inherited from the abstract class of each vertical component and is output by the large language model in response to the prompt word, and use the source code of each concrete adapter class as executable adapter code.

[0144] In this embodiment, based on the syntactic constraints of the standardized abstract interface and the semantic constraints of the standard meta-action library information, when guiding the large language model to extract the interface implementations of each robot component from the native interface document, it is first necessary to clarify the component composition of the target robot. For example, an industrial robotic arm includes three core components: the robotic arm body, the end-effector vision camera, and the force sensor. The system can first identify the native interface modules corresponding to these three components by parsing the directory and chapter structure of the native interface document. Then, according to the definition of the standardized abstract interface, it matches the "ArmBase" vertical abstract class for the robotic arm body, the "CameraBase" vertical abstract class for the vision camera, and the "ForceSensorBase" vertical abstract class for the force sensor, completing the one-to-one mapping between components and abstract classes.

[0145] Next, standard meta-actions are selected for each component type: taking the robotic arm body as an example, this application can select three core meta-actions from the standard meta-action library: "joint space movement", "Cartesian space movement", and "end-effector switching". Each meta-action contains clear parameter constraints. For example, "joint space movement" requires input of a list of joint angles (in degrees) with 6 degrees of freedom and movement speed (in mm / s), and output includes execution status code (0 indicates success, non-zero indicates failure) and current joint angle feedback. For the vision camera, three meta-actions are selected: "taking a picture", "setting resolution", and "acquiring image data". The "taking a picture" meta-action requires the output image resolution to be no less than 1920×1080 and the format to be JPEG or PNG.

[0146] Subsequently, the system can construct a structured prompt word input large language model. The prompt words can contain three core pieces of information: First, key fragments of the native interface documentation, such as the description, parameter description, and return value example of the "move_joints(angles:list, speed: float) -> tuple" method in the robotic arm's native interface documentation; second, the definition of the corresponding vertical abstract class, such as the method signature of "joint_move(angle_list: List[float], move_speed:float) -> Dict[str, Any]" in the ArmBase class; and third, the constraints of the standard meta-action, such as "the meta-action of joint space movement requires the input angle list to be 6 in length, the speed range to be 0.1-10.0 mm / s, and the output to contain the two keys 'status' and 'current_angles'".

[0147] The prompt is as follows: "Please generate robotic arm adapter code that inherits from the ArmBase class based on the following information: 1. Native interface documentation snippet: The move_joints method takes angles (list type, length 6) and speed (float type), and returns (success: bool, current_angles: list); 2. ArmBase class method signature: joint_move(angle_list: List[float], move_speed: float) -> Dict[str, Any]; 3. Standard meta-motion constraints: Joint space movement must ensure that angle_list has a length of 6, move_speed ranges from 0.1 to 10.0, and the returned dictionary contains 'status' (value is 'success' or 'failed') and 'current_angles' (list type). Please map the native interface move_joints to the joint_move method and handle parameter type conversion and return value format conversion."

[0148] After receiving the prompt words, the large language model generates preliminary adapter code. For example, the implementation of the `joint_move` method in the robotic arm adapter first checks whether the length of the input `angle_list` is 6 and whether `move_speed` is within a valid range. If not, it directly returns a failure status. Then, it calls the native interface `move_joints(angles=angle_list, speed=move_speed)` to obtain the returned `success` and `current_angles`. Finally, it converts the returned result into a dictionary format, such as `{'status': 'success' if success else 'failed', 'current_angles':current_angles}`. After the code is generated, the system will automatically trigger a verification process: First, the pylint tool will be used to check for syntax errors, such as undefined variables or mismatched parameter types. Then, the semantic verification module will be used to compare the code with the standard meta-actions, such as checking whether the input parameters of the joint_move method contain 6 angle values ​​and whether the returned dictionary contains the specified key. If the verification fails, the system will send the error information to the large language model for secondary correction, such as prompting "the dictionary returned by the joint_move method is missing the 'current_angles' key. Please supplement the current_angles data returned by the native interface", until the generated code fully meets the constraints.

[0149] This dual constraint mechanism, which combines standardized abstract interfaces and standard meta-action libraries, not only reduces the risk of semantic deviation when generating adapter code from large language models, but also ensures that robot component adapters from different manufacturers and models can follow a unified interface specification.

[0150] In one embodiment, loading and registering the executable adapter code into a preset robot management module in step S130 may include:

[0151] S131: Perform static syntax checking and key API pattern verification on the executable adapter code.

[0152] S132: After the executable adapter code passes verification, the executable adapter code and the corresponding configuration file are packaged into an adapter package.

[0153] S133: During system runtime, the adapter package is loaded into memory using dynamic module loading technology, and the initialization function in the adapter package is called to create an adapter instance, which is then registered to a preset robot management module.

[0154] In this embodiment, when loading and registering the executable adapter code into the preset robot management module, static syntax checking and key API pattern verification can be performed on the executable adapter code first. Static syntax checking can be performed using specialized tools. For example, for Python code, the flake8 tool can be used to detect syntax errors, indentation issues, and code style that does not conform to the PEP8 standard. For Java code, the Checkstyle tool can be used to verify the syntactic correctness of class structure and method definitions. Key API pattern verification focuses on whether the calling logic of native interfaces in the adapter code conforms to preset specifications. For example, it checks whether the robotic arm adapter correctly calls the native SDK's "move_joints" interface, and whether the order of parameter passing is consistent with the native interface documentation, avoiding logical errors such as "passing the speed parameter to the angle parameter position." Simultaneously, the verification module scans the code for unauthorized API calls, ensuring that the adapter only uses functional interfaces explicitly permitted in the native interface documentation, preventing security risks.

[0155] After the adapter code passes static syntax checking and key API pattern verification, the system automatically generates the corresponding configuration file. The configuration file can be in JSON format and includes basic adapter information (such as the adapted robot model, part type, and version number), the path to the dependent native SDKs, initialization parameters (such as the default camera resolution and the number of degrees of freedom of the robotic arm), and health check intervals. Subsequently, the system packages the adapter code and configuration file into a compressed file with the ".adapter" extension. The compressed file also includes a verification file to verify the integrity of the package during loading and prevent file tampering.

[0156] During system runtime, dynamic module loading techniques (such as Python's importlib module or Java's ClassLoader) can be used to load the adapter package into memory. During the loading process, the system first reads the verification file in the compressed package and verifies the integrity of the adapter code and configuration file using a hash algorithm. If the verification passes, the initialization parameters in the configuration file are parsed, and the "init_adapter" initialization function in the adapter package is called to create an adapter instance based on the parameters.

[0157] For example, when a camera adapter instance is created, the camera's shooting resolution can be initialized according to the "default_resolution" parameter in the configuration file, and it can be connected to the native SDK at the specified path. After the adapter instance is created, the system calls the "register_adapter" method of the robot management module to register the adapter instance in the management module's component adapter registry. The registry uses a dictionary structure, with "robot model-component type" as the key and the adapter instance as the value, facilitating quick lookup and retrieval later. After registration, the robot management module can also send a heartbeat detection request to the adapter instance to confirm that the instance is in a normal operating state, thus completing the entire loading and registration process.

[0158] This modular loading and registration mechanism ensures both the scalability of the adapter and the stability and security of the system during operation.

[0159] In one embodiment, such as Figure 3 As shown, Figure 3 This application provides a flowchart illustrating a unified control method for an embodied intelligent robot. The application also provides a unified control method for an embodied intelligent robot, applied to a general control system integrating at least one digital robot. The digital robot is generated and registered using the unified access method described in any of the above embodiments. The method may include:

[0160] S210: Receives task instructions from upper-layer applications.

[0161] In this step, the task instructions issued by the upper-layer application are usually transmitted in a structured data format (such as JSON, ProtoBuf), which includes core fields such as task ID, target robot identifier, task type (such as "workpiece gripping", "environmental inspection", "equipment debugging"), task parameters (such as gripping coordinates, inspection path, debugging threshold) and task priority.

[0162] For example, a "workpiece gripping" task instruction issued by an upper-level application in industrial production might be: {"task_id": "T20240515001", "robot_id": "IRB120_001", "task_type": "gripper_pick", "params": {"target_position": [1500.0, 800.0, 500.0], "gripper_force": 50.0},"priority": 2}. The system can perform a validity check on the received task instruction, including verifying whether the task ID is unique, whether the target robot identifier exists in the robot management module's registry, and whether the data type and value range of the task parameters conform to the standard (e.g., the gripping force must be between 0-100N). If the check fails, an error code is returned and the upper-level application is notified to reissue the instruction.

[0163] S220: Decompose task instructions into a set of ordered, atomic standard meta-action sequences.

[0164] In this step, after receiving the task instruction from the upper-layer application via S210, this application can decompose the task instruction into a set of ordered, atomic standard meta-action sequences. The specific decomposition process can be implemented based on a preset task-meta-action mapping rule library, which predefines corresponding meta-action combination logic for different task types.

[0165] For example, for the "workpiece gripping" task type, the rule base specifies that it must sequentially execute four standard meta-actions: "robotic arm moves to above the workpiece in Cartesian space," "robotic arm descends to the workpiece surface," "end-effector closes," and "robotic arm rises to a safe height." The system first parses the "task_type" field in the task instruction to determine the task type, then matches the corresponding meta-action combination template according to the rule base, and then instantiates the meta-action parameters in the template in combination with the task parameters. Taking the meta-action "robotic arm moves to above the workpiece in Cartesian space" as an example, the system extracts the coordinate values ​​[1500.0, 800.0, 500.0] from the task parameter "target_position" and supplements the speed parameter of the robotic arm movement (the recommended speed of 10.0 mm / s in the rule base is taken by default), generating the instantiated meta-action instruction: "{meta_action: 'cartesian_move',params: {target_coords: [1500.0, 800.0, 500.0], speed: 10.0}}.

[0166] For complex tasks (such as "material sorting" tasks with conditional branches), the system can also introduce process control meta-actions (such as "conditional judgment" and "loop execution"). For example, when the task requires "grab the workpiece if the vision camera detects that the workpiece is red, otherwise skip," the decomposed meta-action sequence will include meta-actions such as "camera taking a picture," "color recognition judgment," and "conditional branch execution" to ensure the integrity of the task logic. After decomposition, the system can also perform dependency checks on the meta-action sequence. For example, it can check whether the "end-effector closing" meta-action is executed after the "robotic arm descending to the workpiece surface" meta-action to avoid task failure due to reversed action order.

[0167] S230: For each standard meta-action in the standard meta-action sequence, call the standardized abstract interface exposed by the digital robot that executes the standard meta-action, and pass in standardized instructions that conform to the standardized abstract interface specification.

[0168] In this step, after the task instruction is decomposed into a set of ordered, atomic standard meta-action sequences through S220, for each standard meta-action in the standard meta-action sequence, this application can call the standardized abstract interface exposed by the digital robot that executes the standard meta-action and pass in a standardized instruction that conforms to the standardized abstract interface specification. This standardized instruction is mapped to the corresponding physical robot's native control instruction through the component adapter corresponding to the digital robot and sent for execution.

[0169] Understandably, this application decouples the control logic of the digital robot from that of the physical robot through a standardized abstract interface, so that upper-layer applications do not need to concern themselves with the hardware differences and native instruction formats of the physical robot. For example, when executing the "end-effector closure" meta-action, the system first obtains the corresponding robotic arm adapter instance from the registry of the robot management module based on the "robot_id" in the task instruction, calls its exposed "gripper_close" standardized abstract interface, and passes in parameters that conform to the specification (such as a gripping force of 50.0N). After receiving the standardized instruction, the adapter instance can convert the "gripper_close" interface call into the "set_gripper_force" method call of the physical robot's native SDK according to the predefined mapping rules, and perform parameter conversion according to the parameter format required by the native interface (such as converting the gripping force from float type to int type supported by the native SDK). Finally, the converted native instruction is sent to the control unit of the physical robot for execution.

[0170] During execution, the system can also monitor the status information returned by the physical robot in real time. The adapter instance can convert the physical robot's native status data (e.g., "gripper_status: 1" indicating successful closure) into a standardized status feedback format (e.g., {"status": "success", "gripper_state": "closed"}), and send it back to the general control system through a standardized abstract interface. If the physical robot fails to execute a command (e.g., the native SDK returns "success:False"), the adapter will encapsulate the reason for the failure (e.g., "gripper motor error") into a standardized error message, triggering the system's exception handling process, such as pausing the execution of the current meta-action sequence, recording error logs, and sending alarm notifications to the upper-layer application.

[0171] This instruction invocation mechanism based on standardized abstract interfaces achieves the effect of "one-time instruction writing, multi-robot adaptation". For example, for robotic arms of different brands (such as ABB IRB120 and Fanuc LR Mate 200iD), their native gripper control interfaces are "move_joints" and "joint_movement" respectively. However, after mapping through the corresponding component adapters, the general control system can send instructions through the unified standardized abstract interface "joint_move" without modifying the upper-level control logic, which greatly improves the system's compatibility and development efficiency.

[0172] In one embodiment, the standardized abstract interface exposed by the digital robot that performs the standard meta-action in S230 may include:

[0173] S231: Select the digital robot to execute the standard action based on the type and parameters of the standard action and the metadata of all connected digital robots stored in the preset robot management module.

[0174] S232: Invoke the standardized abstract interface exposed by the digital robot that performs this standard meta-action.

[0175] In this embodiment, when calling the standardized abstract interface exposed by the digital robot that executes the standard meta-action, the appropriate digital robot can be accurately matched and selected based on the type and parameters of the standard meta-action and the metadata of the connected digital robots stored in the robot management module.

[0176] Specifically, the metadata of the robot management module includes the functional attributes of each digital robot (such as supported meta-action types, robotic arm degrees of freedom, and end effector type), performance parameters (such as maximum load and movement speed), and current operating status (such as idle, busy, or faulty). For example, when performing the "camera take a picture" meta-action, the system first filters out digital robots equipped with vision sensors from the metadata, and then matches camera adapter instances that support the resolution based on the "shooting resolution" requirement in the task parameters. If multiple digital robots meet the criteria, the optimal one is selected according to the scheduling rule of "task priority + robot load rate" (such as prioritizing allocation to idle robots with a load rate below 30%).

[0177] After matching is complete, the system can obtain the standardized abstract interface address corresponding to the digital robot through the robot management module. When calling the interface, the standardized instructions must be passed in strict accordance with the preset parameter format. For example, when calling the “camera_capture” interface, the parameters passed in must include fields such as shooting mode (e.g., “single_shot”), resolution (e.g., “1920x1080”) and storage path (e.g., “ / data / captures / 20240515 / ”) to ensure the compatibility and accuracy of the interface call.

[0178] In one embodiment, the standardized instructions conforming to the standardized abstract interface specification passed in S230 may include:

[0179] S233: Obtain the real-time status of the physical robot corresponding to the digital robot performing the standardized action.

[0180] S234: Based on the real-time state and the type and parameters of the standard meta-action, a continuous sequence of trajectory points is generated using a trajectory planning algorithm.

[0181] S235: Encapsulate the trajectory point sequence into a standardized instruction that conforms to the standardized abstract interface specification, and pass it into the standardized abstract interface.

[0182] In this embodiment, before transmitting standardized commands, the system can first obtain the real-time status of the physical robot through the component adapter corresponding to the digital robot. For example, when executing a robotic arm movement motion, the adapter can read raw state data such as the current joint angle, end effector position, and motor temperature from the physical robot's control unit and convert it into a standardized state format (such as {"joint_angles": [0.5, 1.2, -0.3], "end_effector_pos": [1000.0,500.0, 300.0], "motor_temp": 45.0}) and feed it back to the system. The system determines whether the physical robot is in an executable state based on these real-time states. If the motor temperature exceeds a threshold (such as 60°C), the command issuance is paused and a cooling process is triggered.

[0183] Subsequently, the system can combine real-time status and meta-action parameters to generate a continuous sequence of trajectory points using a trajectory planning algorithm. Taking the meta-action of "the robotic arm moving to the target position in Cartesian space" as an example, the task parameters require moving from the current position [1000.0, 500.0, 300.0] to the target position [1500.0, 800.0, 500.0]. The system uses a fifth-order polynomial interpolation algorithm to plan the trajectory, generating a sequence of trajectory points with an interval of 5mm between the starting point and the target point. Each trajectory point includes position coordinates, velocity threshold, and acceleration limit. For scenarios with obstacles, the system can also introduce a collision detection algorithm to perform secondary optimization on the trajectory point sequence, adjusting the coordinates of the trajectory points to avoid obstacles and ensure safe movement.

[0184] Finally, the system can encapsulate the optimized trajectory point sequence into instructions conforming to the standardized abstract interface specification. For example, the robotic arm movement interface requires the instruction format to include a list of trajectory points, a motion mode (such as "linear"), and a completion timeout. The system can convert the trajectory point sequence into a JSON-formatted array, supplement the motion mode and timeout parameters, and pass it to the corresponding standardized abstract interface. After receiving the instructions, the adapter converts the trajectory point sequence into a trajectory data format supported by the robot's native SDK. For example, it converts the coordinates of each trajectory point into millimeter-unit integers required by the native SDK, and then calls the "execute_trajectory" method of the native interface to send the command for execution, achieving precise trajectory control.

[0185] In one embodiment, the method may further include:

[0186] S240: Receive the status data returned by the controller of the physical robot after executing the native control command through the component adapter, convert the status data into a predefined standardized status format, and update it in the status field of the digital robot.

[0187] In this embodiment, the component adapter acts as a communication bridge between the digital robot and the physical robot, enabling it to capture the native state data returned by the physical robot controller in real time. This native data covers the operating parameters of various hardware modules of the physical robot, such as the joint angles of the robotic arm, the current position of the end effector, the real-time speed and temperature of the motor, and the detection values ​​of the sensors. The native state data formats of physical robots of different brands or models vary significantly, and may be binary streams, strings with specific delimiters, or custom structures.

[0188] The component adapter in this application has a built-in state mapping rule table for the corresponding physical robot. The table clearly defines the one-to-one correspondence between the native state fields and the standardized state fields, as well as the rules for data type conversion and unit conversion. For example, if the physical robot returns "joint_angle_1: 30.5" (in degrees), the adapter will map it to "joint_angles[0]: 30.5" in the standardized state according to the rules, and at the same time convert "motor_temp: 55" (in degrees Celsius) in the native data to "motor_temperatures[0]: 55.0" in the standardized state. After the adapter completes the state data conversion, it will send the standardized state data to the state management module of the general control system through a preset communication channel (such as MQTT protocol or HTTP interface).

[0189] After receiving the data, the status management module can locate the corresponding digital robot instance based on its unique identifier and update the instance's status field with standardized status data, including task execution progress (e.g., "3 / 5 meta-actions completed"), hardware operating status (e.g., "Normal" or "Abnormal"), and real-time parameter values. The system can also monitor the updated status data in real time. If an abnormal state is detected (e.g., motor temperature exceeding a threshold or sensor data exceeding normal range), an early warning mechanism will be immediately triggered, generating alarm information including the type of abnormality, the time of occurrence, and the hardware modules involved. This alarm will be synchronized to the monitoring interface of the upper-layer application for timely handling by administrators. This standardized conversion and real-time update mechanism for status data ensures that the general control system can uniformly and accurately grasp the operating status of all connected physical robots, providing reliable data support for subsequent task scheduling, anomaly handling, and system optimization.

[0190] The general control system provided in the embodiments of this application is described below. The general control system described below and the unified access and control method of the embodied intelligent robot described above can be referred to and correspond to each other.

[0191] In one embodiment, such as Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of one general control system provided in an embodiment of this application; this application also provides a general control system, which may include a document acquisition module 110, a code generation module 120, and a loading and registration module 130, specifically including the following:

[0192] Document acquisition module 110 is used to acquire the native interface documents of the target robot.

[0193] The code generation module 120 is used to input the native interface document, the standardized abstract interface of the predefined robot parts, and the predefined standard meta-action library information into the large language model, and generate executable adapter code that conforms to the standardized abstract interface through the large language model.

[0194] The registration module 130 is used to load and register the executable adapter code into a preset robot management module to form a digital robot corresponding to the target robot.

[0195] The digital robot is used to provide external applications with unified control over the target robot through its standardized abstract interface.

[0196] In the above embodiments, by introducing a standardized abstract interface and a large language model-driven adapter code generation mechanism, automated adaptation to the native interfaces of robots from different manufacturers and of different types is achieved, significantly reducing the development cost and cycle of upper-layer applications connecting to multiple robots. Specifically, the unified access method of this application converts the native interface document of the target robot into adapter code conforming to the standardized abstract interface through a large language model. After loading and registration, a digital robot is formed, providing a unified control entry point for upper-layer applications. This effectively solves the problems of fragmented robot interfaces and inconsistent action semantics in the prior art, providing solid technical support for the large-scale application of embodied intelligent robots.

[0197] In one embodiment, such as Figure 5 As shown, Figure 5 This is a schematic diagram of another general control system provided in an embodiment of this application; this application also provides a general control system, which may include an instruction receiving module 210, a task decomposition module 220, and an interface calling module 230, specifically including the following:

[0198] The instruction receiving module 210 is used to receive task instructions issued by the upper-layer application.

[0199] The task decomposition module 220 is used to decompose the task instructions into a set of ordered, atomized standard meta-action sequences.

[0200] The interface calling module 230 is used to call the standardized abstract interface exposed by the digital robot that executes the standard meta-action for each standard meta-action in the standard meta-action sequence, and pass in standardized instructions that conform to the standard abstract interface specification.

[0201] The standardized instructions are mapped to the corresponding native control instructions of the physical robot via the component adapter corresponding to the digital robot and then sent for execution.

[0202] This application's instruction invocation mechanism, based on a standardized abstract interface, achieves the effect of "one-time instruction writing, multi-robot adaptation." For example, for robotic arms of different brands (such as ABB IRB120 and Fanuc LR Mate 200iD), their native gripper control interfaces are "move_joints" and "joint_movement," respectively. However, after mapping through the corresponding component adapters, the general control system can send instructions through the unified "joint_move" standardized abstract interface without modifying the upper-level control logic, greatly improving system compatibility and development efficiency.

[0203] In one embodiment, this application also provides a computer-readable storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the unified access method for an embodied intelligent robot as described in any of the above embodiments, and / or the steps of the unified control method for an embodied intelligent robot as described in any of the above embodiments.

[0204] In one embodiment, this application also provides a computer device, including: one or more processors, and memory.

[0205] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the unified access method for an embodied intelligent robot as described in any of the above embodiments, and / or the steps of the unified control method for an embodied intelligent robot as described in any of the above embodiments.

[0206] Indicatively, such as Figure 6 As shown, Figure 6 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 6The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the unified access and control method for the embodied intelligent robot of any of the above embodiments.

[0207] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0208] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0209] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0210] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0211] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A unified access method for embodied intelligent robots, characterized in that, The method is applied to a general control system, including: Obtain the target robot's native API documentation; The native interface document, the standardized abstract interface of the predefined robot parts, and the predefined standard meta-action library information are input into the large language model, and executable adapter code that conforms to the standardized abstract interface is generated through the large language model. The executable adapter code is loaded and registered into a preset robot management module to form a digital robot corresponding to the target robot; The digital robot is used to provide external applications with unified control over the target robot through its standardized abstract interface. The standardized abstract interface for the predefined robot components is defined according to a multi-layered architecture, including: The component base class defines the common basic operation methods that all robot components must implement; An abstract class for vertical components, which inherits from the base class of components, defines special functional methods for components of a specific category; The executable adapter code is implemented by a concrete adapter class that inherits from the vertical component abstract class; The step of generating executable adapter code conforming to the standardized abstract interface through the large language model includes: Based on the standardized abstract interface, determine the vertical component abstract class corresponding to each robot component of the target robot; Based on the type of each robot component, the corresponding standard meta-action definitions are selected from the standard meta-action library information; Based on the descriptions of each robot component in the native interface document, the definition of the corresponding vertical component abstract class, and the selected standard meta-action definitions, prompt words are constructed and input into the large language model; Receive the source code of concrete adapter classes that are inherited from the abstract classes of each vertical component and are output by the large language model in response to the prompt word, and use the source code of each concrete adapter class as executable adapter code.

2. The unified access method according to claim 1, characterized in that, The step of loading and registering the executable adapter code into the preset robot management module includes: Static syntax checking and key API pattern verification are performed on the executable adapter code; After the executable adapter code passes verification, the executable adapter code and the corresponding configuration file are packaged into an adapter package; During system runtime, the adapter package is loaded into memory using dynamic module loading technology, and the initialization function in the adapter package is called to create an adapter instance, which is then registered to the preset robot management module.

3. A unified control method for an embodied intelligent robot, characterized in that, The method is applied to a general control system integrating at least one digital robot, wherein the digital robot is generated and registered using the unified access method according to any one of claims 1 to 2, and the method includes: Receive task instructions from upper-layer applications; The task instructions are decomposed into a set of ordered, atomized standard meta-action sequences; For each standard meta-action in the standard meta-action sequence, the standardized abstract interface exposed by the digital robot executing the standard meta-action is invoked, and a standardized instruction conforming to the standard abstract interface specification is passed in; The standardized instructions are mapped to the corresponding native control instructions of the physical robot via the component adapter corresponding to the digital robot and then sent for execution. The standardized abstract interface exposed by the digital robot that invokes the standard meta-action includes: Based on the type and parameters of the standard meta-action, and the metadata of all connected digital robots stored in the preset robot management module, select the digital robot to execute the standard meta-action. Invoke the standardized abstract interface exposed by the digital robot that performs the standard meta-action; The input standardized instructions conforming to the standardized abstract interface specification include: Obtain the real-time status of the physical robot corresponding to the digital robot that performs the standard meta-action; Based on the real-time status and the type and parameters of the standard meta-action, a continuous sequence of trajectory points is generated using a trajectory planning algorithm; The trajectory point sequence is encapsulated into standardized instructions that conform to the standardized abstract interface specification and then passed into the standardized abstract interface.

4. The unified control method according to claim 3, characterized in that, The method further includes: The component adapter receives the status data returned by the controller of the physical robot after executing the native control command, converts the status data into a predefined standardized status format, and then updates the status field of the digital robot.

5. A general-purpose control system, characterized in that, include: The document acquisition module is used to acquire the native interface documents of the target robot; The code generation module is used to input the native interface document, the standardized abstract interface of the predefined robot parts, and the predefined standard meta-action library information into the large language model, and generate executable adapter code that conforms to the standardized abstract interface through the large language model; The loading and registration module is used to load and register the executable adapter code into a preset robot management module to form a digital robot corresponding to the target robot; The digital robot is used to provide external applications with unified control over the target robot through its standardized abstract interface. The standardized abstract interface for the predefined robot components is defined according to a multi-layered architecture, including: The component base class defines the common basic operation methods that all robot components must implement; An abstract class for vertical components, which inherits from the base class of components, defines special functional methods for components of a specific category; The executable adapter code is implemented by a concrete adapter class that inherits from the vertical component abstract class; The code generation module generates executable adapter code conforming to the standardized abstract interface using the large language model, including: Based on the standardized abstract interface, determine the vertical component abstract class corresponding to each robot component of the target robot; Based on the type of each robot component, the corresponding standard meta-action definitions are selected from the standard meta-action library information; Based on the descriptions of each robot component in the native interface document, the definition of the corresponding vertical component abstract class, and the selected standard meta-action definitions, prompt words are constructed and input into the large language model; Receive the source code of concrete adapter classes that are inherited from the abstract classes of each vertical component and are output by the large language model in response to the prompt word, and use the source code of each concrete adapter class as executable adapter code.

6. A general-purpose control system, characterized in that, At least one digital robot integrated in the general control system is generated and registered using the unified access method described in any one of claims 1 to 2, including: The instruction receiving module is used to receive task instructions issued by the upper-layer application; The task decomposition module is used to decompose the task instructions into a set of ordered, atomic standard meta-action sequences; The interface calling module is used to call the standardized abstract interface exposed by the digital robot that executes the standard meta-action for each standard meta-action in the standard meta-action sequence, and pass in standardized instructions that conform to the standard abstract interface specification. The standardized instructions are mapped to the corresponding native control instructions of the physical robot via the component adapter corresponding to the digital robot and then sent for execution. The interface calling module calls the standardized abstract interface exposed by the digital robot that executes the standard meta-action, including: Based on the type and parameters of the standard meta-action, and the metadata of all connected digital robots stored in the preset robot management module, select the digital robot to execute the standard meta-action. Invoke the standardized abstract interface exposed by the digital robot that performs the standard meta-action; The interface calling module receives standardized instructions that conform to the standardized abstract interface specification, including: Obtain the real-time status of the physical robot corresponding to the digital robot that performs the standard meta-action; Based on the real-time status and the type and parameters of the standard meta-action, a continuous sequence of trajectory points is generated using a trajectory planning algorithm; The trajectory point sequence is encapsulated into standardized instructions that conform to the standardized abstract interface specification and then passed into the standardized abstract interface.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the unified access method for an embodied intelligent robot as described in any one of claims 1 to 2, and / or the steps of the unified control method for an embodied intelligent robot as described in any one of claims 3 to 4.

8. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the unified access method for an embodied intelligent robot as described in any one of claims 1 to 2, and / or the steps of the unified control method for an embodied intelligent robot as described in any one of claims 3 to 4.

Images