Heterogeneous robot access method and system based on dynamic configuration driving

Abstract

This invention discloses a method and system for heterogeneous robot access based on dynamic configuration driving. By collaborating between the driver layer and the adapter layer, it resolves the differences in communication protocols, control commands, and parameter formats among robots from different manufacturers. The driver layer dynamically generates corresponding basic drivers by reading driver configuration files and automatically selects and executes appropriate driving methods based on control commands. Each robot dynamically adjusts the combination of driver layers according to its characteristics through the driver configuration file, achieving flexible configuration and expansion of drivers. The adapter layer performs semantic conversion of robot control commands and parameter formats by reading adapter configuration files, and converts high-level business commands into robot control commands based on the robot's unique identifier and business requirements, while simultaneously performing necessary mapping of robot inputs and outputs. This invention simplifies the heterogeneous robot access process and has strong scalability and adaptability.

Description

Technical Field

[0001] This invention relates to heterogeneous device access and unified management technology, specifically to a method for accessing heterogeneous robots based on dynamic configuration, belonging to the interdisciplinary technical fields of edge computing, intelligent control, robot systems, and software engineering. Background Technology

[0002] In scenarios such as dam inspection and industrial site maintenance, robots, including cameras, wheeled robots, rail-mounted robots, unmanned boats, and drones, come from diverse sources, use different communication protocols, and have varying instruction sets and parameter formats depending on the manufacturer. Currently, most robot integration and control methods employ explicit programming with specific vendor SDKs or customized interfaces, resulting in point-to-point adaptation and strong coupling. This approach relies on static code and fixed rules, making it difficult to cope with frequent robot model changes, protocol diversification, and changes in the field environment. This leads to long new robot integration cycles, high maintenance costs, and poor reusability.

[0003] In practical applications, business systems typically issue high-level instructions using unified business semantics, such as "execute the predetermined inspection route (execute_route)" and "collect and report monitoring data from segment X (get_data_from_area(X))". To reliably deliver these high-level instructions to different robots, it is necessary to complete cross-vendor instruction semantic mapping, parameter name and hierarchy standardization, communication protocol selection and invocation method matching, and to perform unified semantic restoration and interface alignment of the robot-side return results. Meanwhile, edge environments generally face objective constraints such as unstable links, latency fluctuations, interleaved concurrent instructions, and asynchronous status feedback, placing higher demands on the scheduling capabilities, fault tolerance, and observability of the access layer. Traditional code-driven integration methods often lack declarative configuration and pluggable extensibility, making it difficult to quickly support the linkage and evolution of multiple robots without modifying the code.

[0004] Although robot management platforms and driver frameworks for heterogeneous robots have been proposed in recent years, the following shortcomings still exist in engineering practice: First, the driving capabilities are often based on "fixed code + lightweight templates", with coarse configuration granularity, making it difficult to cover differences in vendor instructions and parameter levels; Second, the conversion from business semantics to robot semantics lacks a unified and externalizable rule description and runtime scheduling mechanism, making it difficult to seamlessly migrate the same business instructions among multiple robots; Third, there is a lack of closed-loop management for "dynamic selection of driving methods at runtime, parameter level conversion, call chain logs and result standardization", resulting in high costs for operation and maintenance diagnosis and problem tracing, and insufficient system scalability and maintainability.

[0005] In summary, the current integration and management of heterogeneous robots faces three main challenges: First, the lack of a unified configuration-driven integration mechanism for multiple protocols and vendors necessitates code modifications for adding or replacing robots, resulting in lengthy integration cycles. Second, the lack of standardized mapping and configurable conversion capabilities between business instruction semantics and robot instructions and parameters leads to insufficient cross-robot reusability and consistency. Third, the lack of dynamic driver selection and result closure at runtime (including parameter-level conversion, unified result format, and call chain log tracing) results in poor system robustness, observability, and operational efficiency. Therefore, a dynamic configuration-driven heterogeneous robot integration method is urgently needed. This method should, without modifying the business code, complete instruction semantics and parameter mapping, driver combination, and runtime scheduling through configuration files, enabling rapid integration, stable execution, and traceable management of multiple robots. Summary of the Invention

[0006] Purpose of the invention: This invention proposes a method and system for heterogeneous robot access based on dynamic configuration, aiming to overcome key problems in existing heterogeneous robot access and management technologies, such as diverse protocols, inconsistent command semantics, large differences in parameter levels, long access cycles for new robots, and lack of dynamic scheduling and closed-loop governance during operation.

[0007] This invention introduces a unified configuration-driven mechanism and a layered architecture. In the robot driver layer and adapter layer, externalizable YAML-formatted configuration files describe communication protocols, instruction mappings, and parameter mappings, respectively. A basic driver library with a unified calling interface (such as HTTP driver, MQTT driver, WebSocket driver, and SSE driver) is constructed. The robot driver dynamically combines and selects the basic driver based on the configuration file, performs parameter level conversion, and reports the call chain log. The adapter layer provides a unified execution entry point, completing the semantic and parameter mapping from business instructions to robot control instructions, target robot routing, and standardized result output. Through this mechanism, robot access with little or no code is achieved, dynamic selection of runtime driver methods, and closed-loop result governance are implemented, improving the scalability and maintainability of the business system.

[0008] The method and system of this invention are applicable to complex scenarios such as dam inspection where multiple protocols and multiple vendors of robots coexist. They can quickly integrate new robots without modifying business code, ensure cross-robot instruction consistency and result alignment, significantly reduce integration and maintenance costs, and improve system reliability, observability and scalability. This solves the problems of untimely response, insufficient reusability and difficulty in traceability of existing solutions in cross-vendor adaptation, rapid evolution and operation assurance.

[0009] Technical Solution: A heterogeneous robot access method based on dynamic configuration drive is proposed. A hierarchical system and configuration externalization mechanism of "adapter layer - robot driver layer - basic driver library" are designed. Through unified execution entry, semantic and parameter mapping, dynamic combination of drivers and closed-loop governance of results, the rapid access and stable linkage of multi-protocol and multi-vendor robots in complex scenarios such as dam inspection are realized.

[0010] In the basic driver library, pluggable basic drivers are built to encapsulate the implementation of different communication protocols. Each basic driver implements specific operation methods according to a specific communication protocol, ensuring seamless communication between the robot and the upper-level business system. All basic drivers provide a unified entry call interface, and the specific communication process is completed within the basic driver, simplifying the management and use of the driver layer.

[0011] At the robot driver layer, the appropriate base driver is dynamically selected and loaded by reading the robot's driver configuration file. Based on the communication protocol (e.g., HTTP) and method (e.g., GET, POST) fields in the configuration file, the robot driver dynamically combines different base drivers and executes robot tasks. The robot driver also performs parameter level transformation according to the requirements of upper-layer business instructions, mapping the parameter level of the upper-layer business system to the parameter level required by the robot, ensuring accurate instruction execution. Simultaneously, the robot driver logs the execution results, providing detailed operation information and supporting traceability and troubleshooting of operation results.

[0012] At the adapter layer, an adapter pool is used to find and select the corresponding adapter for each robot based on its unique identifier. The adapter receives instructions from the upper-layer business system and performs semantic and parameter conversion based on the instruction content and robot characteristics, transforming the upper-layer business instructions into control instructions that the robot can understand. The adapter also performs semantic restoration of the robot's execution results, ensuring that the data returned by the robot meets the requirements of the upper-layer business system before being returned to it. The adapter layer provides a unified execution entry point, ensuring standardized output of instruction routing, execution, and results, thus improving the flexibility and scalability of multi-robot integration.

[0013] This invention realizes the entire process from "basic driver construction → dynamic configuration of robot driver → semantic and parameter conversion of adapter → dynamic selection and execution of adapter", effectively solving the problems of long robot access cycle, cross-vendor adaptation difficulty, inconsistent instruction semantics, complex parameter mapping, and insufficient dynamic scheduling at runtime in the existing technology. It significantly improves the access efficiency in multi-robot environments and ensures the stable operation and efficient collaboration of heterogeneous robots in complex scenarios.

[0014] The method includes the following:

[0015] (1) Building a basic driver

[0016] By constructing pluggable base drivers, communication with different heterogeneous robots is supported. Each base driver implements specific operating methods according to the communication protocol type, ensuring effective communication with heterogeneous robots. These base drivers provide a reliable technical foundation for communication between robots and upper-level business systems, and can handle multiple unified protocols and robot types.

[0017] (2) Dynamic configuration of robot drive

[0018] The robot dynamically selects and loads the basic driver based on the robot's driver configuration file, thereby generating the corresponding robot driver and executing the robot task; by parsing the communication protocol and operation requirements in the driver configuration file, the basic driver is automatically selected, and the parameter level is converted according to the actual needs of the robot; the robot driver will also report the data during the execution process to the upper-level business system.

[0019] (3) Semantic conversion and parameter conversion of the adapter

[0020] The adapter configuration file maps and converts the semantics and parameters between the instructions from the upper-level business system and the actual control instructions of the robot. Based on the mapping relationship in the adapter configuration file, the high-level instructions from the upper-level business system are converted into control instructions that the robot can execute, and the parameter format of the upper-level business system is mapped to the parameter format required by the robot.

[0021] (4) Dynamic selection and execution of the adapter

[0022] During task execution, the corresponding robot's adapter is located and selected using the robot's unique identifier. The adapter flexibly invokes the robot driver according to the upper-level business instructions, executes the corresponding operations, and feeds back the execution results to the upper-level business system. All robot adapters provide a unified call entry point, responsible for receiving upper-level business instructions. This mechanism ensures that each task can be flexibly scheduled and executed, guaranteeing the efficiency and stability of robot operation.

[0023] Furthermore, the specific steps for building the basic driver (1) are as follows:

[0024] (1.1) Driver Utility Class Design: To achieve efficient communication with various heterogeneous robots, this invention designs a pluggable basic driver architecture. Each basic driver encapsulates the communication logic between different communication protocols and the robot, providing a unified entry point call interface. The core idea of ​​the basic driver design is pluggability, that is, the specific implementation of each protocol can be flexibly replaced or extended as needed without modifying the business code.

[0025] Specifically, the pluggable design is achieved through a combination of interfaces and abstract classes. This invention implements this feature using Java, and utilizes the factory and strategy patterns in Java to dynamically select and load communication protocols. In this architecture, the base driver implements a unified entry point, the IDeviceDriver interface, which defines methods for implementing the basic communication protocol and unified calling methods for the base driver, such as sendRequest, receiveResponse, and call methods. The base driver implements different communication protocol-specific operations by inheriting the IDeviceDriver interface.

[0026] By utilizing Java's dependency injection mechanism, the appropriate base driver is dynamically selected and loaded at runtime based on the driver configuration file. This mechanism ensures that the integration of a new communication protocol only requires creating a new base driver and updating the configuration file, without modifying the core code or implementing base drivers for other communication protocols. This design enables heterogeneous robot systems to flexibly expand, supporting multiple communication protocols without affecting the operation of other parts.

[0027] (1.2) Driver Implementation: This part is responsible for handling protocol-specific operations, ensuring that the communication functions of different protocols can be executed as expected. Each communication protocol requires the implementation of specific communication methods, such as sending requests, receiving responses, and publishing messages. By implementing protocol-specific methods, the basic driver can communicate efficiently and stably with the robot. The driver methods implemented in this invention include, but are not limited to, the following:

[0028] (1a) HTTP driver methods: Define methods for calling POST request types, sending data and obtaining response results, and define methods for calling GET request types, sending data and obtaining response results;

[0029] (1b) MQTT-driven methods: Define methods for publishing data to a specified MQTT topic and ensuring timely message delivery; define methods for subscribing to multiple topics and receiving messages from the robot in real time;

[0030] (1c) WebSocket driver methods: Define methods for establishing a WebSocket connection with the robot and providing support for full-duplex communication; define methods for sending messages and methods for receiving messages returned from the robot;

[0031] (1d) SSE-driven method: Define the method responsible for establishing a one-way connection with the server and receiving event streams from the server in real time; define the method for processing event data and passing it to the upper-layer business system for processing;

[0032] (1.3) Unified Invocation of Driver Methods: In this invention, all basic drivers implement a unified call interface to simplify the interaction between the upper-layer business system and the robot. Through the unified call method (i.e., the call interface), the upper-layer business system can flexibly call driver methods of different communication protocols without needing to concern itself with the specific implementation details of the underlying protocols. The call method, as the unified entry point for the basic drivers, receives two parameters: the method name (method) and the method parameters (params). Based on these inputs, the call method can dynamically determine which specific method of the basic driver to invoke.

[0033] When the `call` method is invoked, it first searches for the corresponding actual method in the underlying driver that implements the current communication protocol based on the passed `method` parameter. Through reflection, the `call` method can dynamically identify and execute the appropriate method, extracting the necessary parameters from `params` and passing them as input to that method (e.g., if `method` is `doPost`, it will find the `doPost` method in the HTTP driver and pass in the required parameters). This mechanism not only ensures flexible invocation of methods from different communication protocols but also allows for dynamic selection of the most suitable communication protocol and operation method at runtime based on configuration, without requiring any code modification.

[0034] The basic driver architecture, through its pluggable design, successfully achieves efficient communication with various heterogeneous robots. Each basic driver independently encapsulates communication logic specific to the communication protocol, using a unified interface and methods for invocation, allowing for flexible switching and expansion of driver methods for different communication protocols.

[0035] Furthermore, the dynamic configuration of the robot driver (2) refers to dynamically selecting a suitable basic driver and generating a robot driver based on the robot's communication protocol and operational requirements after reading the robot's driver configuration file. This step combines multiple aspects such as driver configuration file parsing, instruction matching, parameter conversion, and log reporting to ensure that the robot driver can execute efficiently according to business needs and seamlessly connect with the robot's actual communication protocol. The dynamic configuration process of the robot driver is achieved through a three-step method of "driver selection + instruction matching + parameter conversion," thereby realizing the flexible configuration and expansion of the robot driver.

[0036] (2.1) Configuration File Parsing and Driver Selection: Dynamic configuration of the robot driver begins by parsing the robot's driver configuration file to extract the defined communication protocols, operational requirements, and related parameters. The driver configuration file typically contains the communication protocol types required by the robot (such as HTTP, MQTT, WebSocket, etc.) and the specific communication logic under each protocol. Based on the information in the driver configuration file, suitable basic drivers can be flexibly loaded and combined to generate a complete robot driver.

[0037] When the communication protocol field in the driver configuration file specifies `protocol: HTTP`, the robot driver will load the base driver corresponding to the HTTP protocol; if `protocol: MQTT` is specified, the base driver corresponding to the MQTT protocol will be loaded. Similarly, if `protocol: WebSocket` is defined in the driver configuration file, the base driver corresponding to the WebSocket protocol will be loaded. In this way, the communication protocol field in the driver configuration file guides the correct base driver loading process. Each robot defines the corresponding communication protocol field in its driver configuration file according to its specific communication needs, ensuring that the base driver can be loaded on demand, thereby completing the communication task between the robot and the upper-layer business system.

[0038] (2.2) Instruction Matching and Driver Method Invocation: After the robot driver receives the instruction (such as execute_route) parsed by the adapter layer, it will perform instruction matching according to the mapping relationship in the driver configuration file. Specifically, the robot driver will look up the communication protocol and operation method corresponding to the instruction according to the driver configuration file. For example, the configuration file may define the communication protocol field protocol: HTTP and the control instruction endpoint endpoint: execute_route, which means that the execute_route instruction needs to be implemented by the HTTP driver.

[0039] Next, the robot driver determines the specific method corresponding to the instruction based on the `method` field in the driver configuration file. For example, if the driver configuration file defines `method.execute_route.doPost:[url, body]`, this means the `execute_route` instruction needs to call the `doPost` method of the HTTP driver, passing the corresponding `url` and `body` parameters. The robot driver will dynamically select the corresponding base driver (HTTP driver) based on this information and call its `call` method to execute the operation.

[0040] During execution, the robot driver passes parameters from the adapter layer to the base driver. Through this mechanism, the system can automatically select and execute the appropriate base driver method based on the robot instructions and the mapping relationship in the driver configuration file, ensuring accurate execution of robot operations. This design simplifies the instruction-to-driver mapping process, making support for different communication protocols and robots more flexible and efficient.

[0041] (2.3) Parameter Hierarchy Conversion: When the robot driver receives robot instructions from the adapter layer, it typically obtains a flattened Map format of data containing the parameters required for the robot to perform operations. However, the parameter format inside the robot may differ from the transmission format of the adapter layer, often exhibiting hierarchical relationships or data format differences. Therefore, the robot driver needs to perform hierarchical conversion on these parameters to ensure that the robot can correctly understand and use these parameters.

[0042] The robot driver, based on the parameter hierarchy mapping fields defined in the driver configuration file, transforms the flattened parameters (e.g., routeId: 123, temperature: 25) passed from the upper-layer business system into a nested hierarchical structure desired by the robot, tailored to each robot's needs. For example, the robot might require the routeId parameter to be nested under a data field, becoming {data: {routeId: 123, temperature: 25}}, or it might have more levels and different naming conventions. This transformation ensures that the parameter format of the upper-layer business system matches the parameter format required by the robot's internal system.

[0043] This process typically relies on parameter hierarchical mapping fields in the driver configuration file. In the driver configuration file, a `param_mapping` field is defined, specifying how to map the parameter formats of the upper-layer business system to the parameter formats required internally by the robot. This allows the robot driver to perform corresponding conversion operations based on these mapping relationships. In this way, the driver layer can flexibly adjust the parameters according to the robot's specific structural requirements.

[0044] In practice, the robot driver reads the parameter hierarchy mapping field in the driver configuration file, iterates through the incoming parameters, and converts them into a format that the robot can recognize as needed. For complex nested structures, it processes them recursively to ensure that all parameters are organized and converted according to the robot's requirements. In this way, the robot driver ensures that the robot receives parameters in the correct format when performing tasks, avoiding operation failures due to parameter format mismatches.

[0045] (2.4) Log Reporting: Each time the robot drives a task, it records detailed operation logs, including the operation type, parameters used, operation result (such as success or failure), and operation time. This log information will be reported to the upper-level business system for subsequent log analysis, monitoring, and troubleshooting. The log information not only helps in fault diagnosis but also provides traceable data support for performance optimization.

[0046] These log messages are reported through a centrally managed logging system, which can choose to transmit log data to the upper-level business system on a scheduled basis or as needed. The storage and analysis of logs can help developers monitor the robot's operating status in real time, promptly identify potential robot malfunctions or performance bottlenecks, and ensure stable system operation.

[0047] The log reporting mechanism not only provides reliable fault diagnosis support, but also enables transparent management of the robot operation process, enhancing the observability and maintainability of heterogeneous robot management.

[0048] Furthermore, the semantic conversion and parameter conversion of the adapter (3) refers to the semantic and parameter conversion between the instructions and parameter formats of the upper-level business system and the actual control instructions and parameter formats of the robot, to ensure that the upper-level business instructions can be correctly mapped into control instructions that the robot can execute. By reading the mapping relationship in the adapter configuration file, the instructions and parameters of the upper-level business system are converted into a format that the robot can recognize, and the robot's response results are restored to a format that the upper-level business system can understand. This process mainly includes three steps: instruction semantic conversion, input parameter semantic mapping, and output parameter semantic restoration.

[0049] (3.1) Command Semantic Conversion: The purpose of command semantic conversion is to convert abstract commands from the upper-level business system (such as executeRoute) into control commands (such as execute_route) that the robot can understand and execute. Upper-level business systems typically use high-level commands to describe tasks, while the robot needs to operate according to its specific control commands. The adapter converts the upper-level business commands (executeRoute) into the commands (execute_route) required by the robot by consulting the mapping fields in the adapter configuration file (such as convert.origin.executeRoute:execute_route). In this way, upper-level business commands can be accurately converted into robot-specific control commands, ensuring that the tasks executed by the robot are consistent with business requirements.

[0050] (3.2) Input Parameter Semantic Mapping: The purpose of input parameter semantic mapping is to convert the parameter names passed by the upper-layer business system to the parameter names required by the robot to perform the task. The upper-layer business system usually uses a standardized naming rule, while the robot may have its own specific naming requirements and formats. For example, the upper-layer business system may pass the parameter routeId, but the robot requires this parameter to be route_id. In the adapter configuration file, this is represented by the field mapping.input.routeId: route_id. Therefore, the adapter needs to map the parameter names of the upper-layer business system to the parameter names expected by the robot according to the mapping relationship fields defined in the adapter configuration file.

[0051] This semantic mapping ensures consistent parameter transmission between the upper-level business system and the robot, thus avoiding robot operation errors caused by mismatched parameter names or incorrect formats. In this way, the adapter can provide effective parameter conversion and adaptation between different robots, ensuring that the robot can correctly understand and execute upper-level business instructions.

[0052] (3.3) Output Parameter Semantic Restoration: The purpose of output parameter semantic restoration is to convert the raw data returned by the robot into a format that the upper-layer business system can understand and use. The results returned by the robot after performing an operation are usually in a robot-specific format, which may include status codes, response data, or robot-specific attributes. The upper-layer business system needs these returned results to be processed and displayed in a unified and standardized form. Therefore, the adapter needs to convert the results returned by the robot into the semantics and structure expected by the upper-layer business system based on the mapping relationship fields in the adapter configuration file.

[0053] The adapter converts the raw data fields returned by the robot (e.g., statusCode: 200 or responseData: {temp: 25, humidity: 60}) into a format that the upper-layer business system can understand, based on the mapping fields in the configuration file. For example, statusCode: 200 returned by the robot may need to be restored to status: success, and the raw data field temp returned by the robot may need to be mapped to temperature.

[0054] By using the adapter's semantic and parameter conversion, compatibility and consistency between different levels and different robots can be ensured. This ensures that upper-level business instructions can be accurately mapped to robot control instructions and correctly restored when the robot returns results. This design makes the interaction between robot drive and upper-level business systems smoother and more efficient.

[0055] Furthermore, the dynamic selection and execution of the adapter (4) refers to the adapter layer dynamically selecting a suitable robot adapter and executing robot-driven operations based on the robot's unique identifier after receiving the upper-layer business instruction. This process not only ensures the correct execution of robot instructions but also dynamically adapts to the needs of different robots and communication protocols. This process includes three key steps: adapter selection and matching, robot-driven invocation and execution, and execution result feedback and business layer response.

[0056] (4.1) Adapter Selection and Matching: Upon receiving instructions from the upper-layer business system, the adapter layer first locates and selects the corresponding robot adapter based on the robot's unique identifier. Each robot has an independent adapter, and the adapter selection depends on the robot's identifier and its communication protocol. The adapter layer reads the adapter configuration file, identifies the robot's communication protocol (such as HTTP, MQTT, WebSocket, etc.), and then selects and loads the corresponding robot adapter based on the protocol type. In this way, robot adapters can be flexibly selected and configured, ensuring seamless communication between the robot and the upper-layer business system.

[0057] For example, when a robot's unique identifier is passed to the adapter layer, the adapter layer looks up the corresponding entry in the adapter configuration file to determine the communication protocol and required drive method used by the robot, and then matches the correct robot adapter for processing. This process ensures the robot's independence and flexible selection of communication protocols, avoiding the complexity of hard coding and manual configuration.

[0058] (4.2) Robot driver invocation and execution: All robot adapters provide a unified call entry point handleCommand interface. The upper-layer business system issues commands through the handleCommand interface. After receiving the handleCommand request from the upper-layer business system, the adapter first parses the command content and performs semantic conversion of control commands and parameter formats according to the information in the adapter configuration file, and dynamically selects the robot driver corresponding to the command.

[0059] Specifically, when the upper layer calls the `handleCommand` interface, the adapter extracts the relevant operations (such as `execute_route`) and required parameters from the instruction, and then looks up the corresponding communication protocol and driver method according to the adapter configuration file. The adapter finds the robot driver associated with the instruction by reading the configuration file and then calls the corresponding driver's method. In this way, the upper-layer business system only needs to focus on the transmission of instructions and parameters, without needing to handle driver selection and method invocation; the adapter automatically completes these operations based on the instruction content and the adapter configuration file.

[0060] This unified `handleCommand` interface simplifies the interaction between upper-layer business systems and robots. Commands are sent via this method, and the adapter selects the appropriate driver based on the command type. This design significantly simplifies the use and maintenance of heterogeneous robots, ensuring dynamic mapping and flexible invocation of commands to driver methods, while avoiding coupling between upper-layer business systems and specific robot drivers.

[0061] (4.3) Execution Result Feedback and Business Layer Response: After the robot operation is completed, the robot driver returns the execution result to the adapter. The adapter performs necessary transformations and processing based on the data returned by the robot, and then feeds the result back to the upper-layer business system. Once the adapter completes the result restoration, it transmits the result back to the upper-layer business system, completing the task loop. This feedback information typically includes the operation status (success or failure), relevant data, execution logs, etc. After receiving the execution result, the upper-layer business system further processes this data to complete subsequent logical operations, such as updating the interface, triggering alarms, or recording logs.

[0062] Through this series of dynamic selection and execution processes, this invention ensures seamless integration between robot-driven operations and upper-level business instructions, and flexibly selects appropriate adapters and driving methods according to the needs of different robots and communication protocols. This process not only enhances the adaptability of heterogeneous robot management but also provides powerful flexibility and scalability for robot management and operation.

[0063] Through the dynamic configuration of robot drives, instruction matching and drive method invocation, parameter hierarchy conversion, and semantic conversion and execution of adapters, this invention realizes a closed-loop control chain from robot access management to robot operation execution and feedback adjustment, significantly improving the stability, execution efficiency, and scalability of heterogeneous robot management in multi-protocol, multi-vendor robot environments. By dynamically selecting drives and flexibly configuring robot parameters and instruction mapping, this invention possesses the technical advantages of high adaptability and multi-robot collaboration.

[0064] Furthermore, by applying the above method to a complex heterogeneous robot management system, seamless access and stable execution of various robots and protocols can be achieved. In environments such as dam inspection and industrial site maintenance, this invention can quickly respond to robot access needs, enabling flexible configuration and dynamic selection of robot drives, thereby optimizing robot management and execution efficiency. By reducing manual intervention and lowering the complexity of robot access, it solves problems such as insufficient robot support and long access cycles in traditional robot access processes, improving the reliability and efficiency of the entire system and ensuring that critical tasks and operations are completed in an orderly and efficient manner.

[0065] The heterogeneous robot access system based on dynamic configuration includes the following modules:

[0066] Basic Driver Setup Module: This module encapsulates the communication protocol between heterogeneous robots and upper-layer business systems by building pluggable basic drivers; each basic driver implements the corresponding operation method according to different communication protocols.

[0067] Robot Drive Dynamic Configuration Module: This module dynamically selects and loads the basic driver based on the robot's driver configuration file, thereby generating the corresponding robot driver and executing the robot's operation tasks; by parsing the communication protocol and operation requirements in the driver configuration file, it automatically selects the basic driver and performs parameter level conversion according to the robot's actual needs; the robot drive dynamic configuration module also reports the data during the execution process to the upper-layer business system.

[0068] Semantic conversion and parameter conversion module: This module maps and converts the semantics and parameters between the instructions of the upper-level business system and the actual control instructions of the robot through an adapter; according to the mapping relationship in the adapter configuration file, it converts the high-level instructions of the upper-level business system into control instructions that the robot can execute, and maps the parameter format of the upper-level business system to the parameter format required by the robot.

[0069] Dynamic Selection and Execution Module: This module finds and selects the corresponding robot adapter based on the robot's unique identifier. Each robot has a unique adapter, which provides a unified call entry point, is responsible for receiving upper-layer business instructions, and passing the instructions to the robot driver. The adapter calls the robot driver through the business instructions, executes the corresponding operation, and returns the result to the upper-layer business system.

[0070] The implementation process and methods of the system are the same, and will not be repeated here.

[0071] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the heterogeneous robot access method based on dynamic configuration drive as described above.

[0072] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the heterogeneous robot access method based on dynamic configuration drive as described above.

[0073] Beneficial Effects: Compared with existing heterogeneous robot access management solutions, this invention addresses the problems of poor robot compatibility, long access cycles, inconsistent parameter formats, and difficult maintenance in traditional robot access methods. It proposes a heterogeneous robot access method and system based on dynamic configuration driving. By introducing a flexible robot driver configuration mechanism, it can dynamically load and adapt the basic driver according to the specific needs of the robot, simplifying the robot access process and greatly improving the efficiency of new robot access and the scalability of the heterogeneous robot management system. The method ensures seamless integration between upper-layer business instructions and robot execution instructions through a unified instruction semantic conversion and parameter mapping mechanism, effectively reducing robot operation errors caused by parameter format mismatch or inconsistent instruction semantics. During robot driver execution, efficient collaboration between various robots and protocols is ensured through parameter hierarchical conversion and dynamic selection of appropriate driver methods. During task execution, the adapter can automatically select and call the appropriate robot driver, avoiding manual intervention and improving the automation level of task execution. Simultaneously, through the reporting and feedback mechanism of robot execution logs, the robot status can be monitored in real time, and task allocation can be dynamically adjusted according to the execution results, realizing closed-loop control of task execution and enhancing the robustness and fault tolerance of the system. The robot access management method of this invention has strong adaptability, flexibility, and scalability, and can be widely applied in fields such as dam inspection, industrial operation and maintenance, and intelligent manufacturing. By simplifying the robot access process, improving task execution efficiency, and enhancing system stability, this invention significantly improves the intelligence level of robot management and has important engineering application value and social safety significance. Attached Figure Description

[0074] Figure 1 This is a schematic diagram illustrating the heterogeneous robot access principle of an embodiment of the present invention;

[0075] Figure 2 This is a flowchart illustrating the heterogeneous robot access process according to an embodiment of the present invention. Detailed Implementation

[0076] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading the present invention, any modifications of the present invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.

[0077] The heterogeneous robot access system based on dynamic configuration includes the following modules:

[0078] Basic Driver Setup Module: This module encapsulates the communication protocol between heterogeneous robots and upper-layer business systems by building pluggable basic drivers; each basic driver implements the corresponding operation method according to different communication protocols.

[0079] Robot Drive Dynamic Configuration Module: This module dynamically selects and loads the basic driver based on the robot's driver configuration file, thereby generating the corresponding robot driver and executing the robot's operation tasks; by parsing the communication protocol and operation requirements in the driver configuration file, it automatically selects the basic driver and performs parameter level conversion according to the robot's actual needs; the robot drive dynamic configuration module also reports the data during the execution process to the upper-layer business system.

[0080] Semantic conversion and parameter conversion module: This module maps and converts the semantics and parameters between the instructions of the upper-level business system and the actual control instructions of the robot through an adapter; according to the mapping relationship in the adapter configuration file, it converts the high-level instructions of the upper-level business system into control instructions that the robot can execute, and maps the parameter format of the upper-level business system to the parameter format required by the robot.

[0081] Dynamic Selection and Execution Module: This module finds and selects the corresponding robot adapter based on the robot's unique identifier. Each robot has a unique adapter, which provides a unified call entry point, is responsible for receiving upper-layer business instructions, and passing the instructions to the robot driver. The adapter calls the robot driver through the business instructions, executes the corresponding operation, and returns the result to the upper-layer business system.

[0082] like Figure 1 As shown, a heterogeneous robot access method based on dynamic configuration is used. The heterogeneous robot system includes different robot communication protocols. The implementation of the method includes the following steps:

[0083] (1) Building the basic driver: Focusing on the design, implementation and unified calling mechanism of the basic driver architecture, to ensure that a "pluggable, manageable and observable" communication base is achieved in multi-protocol and multi-vendor robot scenarios.

[0084] (1.1) Driver Utility Class Design: To adapt to efficient communication between robots from multiple protocols and manufacturers, a pluggable basic driver architecture was designed. Each basic driver encapsulates the communication logic between different communication protocols and the robot. The basic driver provides a unified entry point call interface, simplifying the complexity of upper-layer calls. The core idea of ​​the basic driver architecture is pluggability, that is, the specific implementation of each protocol can be flexibly replaced or extended as needed without modifying the business code.

[0085] Specifically, the pluggable design is achieved through a combination of interfaces and abstract classes. This invention implements this feature using Java, and utilizes the factory and strategy patterns in Java to dynamically select and load communication protocols. In this architecture, the base driver implements a unified entry point, the IDeviceDriver interface, which defines methods for implementing the basic communication protocol and unified calling methods for the base driver, such as sendRequest, receiveResponse, and call methods. The base driver implements different communication protocol-specific operations by inheriting the IDeviceDriver interface.

[0086] By utilizing Java's dependency injection mechanism, the appropriate base driver is dynamically selected and loaded at runtime based on the driver configuration file. This mechanism ensures that the integration of a new communication protocol only requires creating a new base driver and updating the configuration file, without modifying the core code or implementing base drivers for other communication protocols. This design enables heterogeneous robot systems to flexibly expand, supporting multiple communication protocols without affecting the operation of other parts.

[0087] like Figure 1 As shown, the HTTPDriver, SSEDriver, MQTTDriver, etc., displayed in the driver layer basic driver construction module are the aforementioned pluggable basic drivers. These basic drivers uniformly implement the IDeviceDriver interface. Effective communication with heterogeneous robots is achieved through different communication protocols. For example... Figure 2 The heterogeneous robot access process shown requires that all heterogeneous robots first need to dynamically load all basic drivers according to the robot's driver configuration file to build the robot driver. Only after the robot driver is successfully built will the adapter configuration file be read to build the robot adapter. If the robot driver construction fails, detailed information about the driver construction failure will be returned.

[0088] (1.2) Driver Implementation: This part is responsible for mapping the unified interface calls to the actual communication actions of each communication protocol, ensuring that different communication protocols can complete request construction, sending, receiving, and result parsing as expected. Each type of communication protocol implements its own send / receive and session management capabilities, enabling efficient and stable communication with the robot through protocol-specific methods; the upper-layer business system only needs to provide the method name and parameters, and the basic driver handles the remaining details and returns standardized results. Specific driver methods implemented in the example include, but are not limited to, the following:

[0089] (1a) HTTP driver methods: Define methods for calling POST request types, sending data and obtaining response results, and define methods for calling GET request types, sending data and obtaining response results;

[0090] (1b) MQTT-driven methods: Define methods for publishing data to a specified MQTT topic and ensuring timely message delivery; define methods for subscribing to multiple topics and receiving messages from the robot in real time;

[0091] (1c) WebSocket driver methods: Define methods for establishing a WebSocket connection with the robot and providing support for full-duplex communication; define methods for sending messages and methods for receiving messages returned from the robot;

[0092] (1d) SSE-driven method: Define the method responsible for establishing a one-way connection with the server and receiving event streams from the server in real time; define the method for processing event data and passing it to the upper-layer business system for processing;

[0093] (1.3) Unified Invocation of Driver Methods: All basic drivers implement a unified call interface to simplify the interaction between the upper-layer business system and the robot. The call method (i.e., the call interface) receives two inputs: method, which represents the name of the driver method to be executed, and params, which represents the set of parameters required for this call. During runtime, the robot driver selects the target communication protocol and the corresponding basic driver according to the driver configuration file. The call method then completes the method location, parameter preparation, and actual execution within the basic driver, thereby decoupling "which protocol to choose" and "how to make the specific call".

[0094] When the `call` method is invoked, it first searches for the corresponding actual method in the underlying driver that implements the current communication protocol based on the passed `method` parameter. Through reflection, the `call` method can dynamically identify and execute the appropriate method, extracting the necessary parameters from `params` and passing them as input to that method (e.g., if `method` is `doPost`, it will find the `doPost` method in the HTTP driver and pass in the required parameters). This mechanism not only ensures flexible invocation of methods from different communication protocols but also allows for dynamic selection of the most suitable communication protocol and operation method at runtime based on configuration, without requiring any code modification.

[0095] Combination Figure 1As can be seen in the driver layer basic driver construction module, each basic driver implements the IDeviceDriver interface. The IDeviceDriver interface encapsulates the unified call interface for all basic drivers. All basic drivers need to implement the IDeviceDriver call interface, so that the basic drivers provide a unified call entry point to the outside world. The robot driver only needs to call the call interface once to complete method parsing, parameter preparation and protocol execution, forming a clear and scalable "unified entry point - protocol implementation" mechanism.

[0096] The basic driver architecture, through a pluggable design, successfully achieves efficient communication with various heterogeneous robots. Each protocol driver class independently encapsulates protocol-specific communication logic and uses a unified interface and methods for invocation, allowing for flexible switching and extension of driver methods for different protocols.

[0097] (2) Dynamic configuration of robot drivers: The robot's driver configuration file is read, and a suitable basic driver is dynamically selected and generated based on the robot's communication protocol and operational requirements. This step combines multiple aspects such as driver configuration file parsing, instruction matching, parameter conversion, and log reporting to ensure that the robot driver can execute efficiently according to business needs and seamlessly connect with the robot's actual communication protocol. The dynamic configuration process of robot drivers is achieved through a three-step method of "driver selection + instruction matching + parameter conversion," thereby realizing flexible configuration and expansion of robot drivers.

[0098] (2.1) Configuration File Parsing and Driver Selection: Dynamic configuration of the robot driver begins by parsing the robot's driver configuration file to extract the defined communication protocols, operational requirements, and related parameters. The driver configuration file typically contains the communication protocol types required by the robot (such as HTTP, MQTT, WebSocket, etc.) and the specific communication logic under each protocol. Based on the information in the driver configuration file, suitable basic drivers can be flexibly loaded and combined to generate a complete robot driver.

[0099] When the communication protocol field in the driver configuration file specifies `protocol: HTTP`, the robot driver will load the base driver corresponding to the HTTP protocol; if `protocol: MQTT` is specified, the base driver corresponding to the MQTT protocol will be loaded. Similarly, if `protocol: WebSocket` is defined in the driver configuration file, the base driver corresponding to the WebSocket protocol will be loaded. In this way, the communication protocol field in the driver configuration file guides the correct base driver loading process. Each robot defines the corresponding communication protocol field in its driver configuration file according to its specific communication needs, ensuring that the base driver can be loaded on demand, thereby completing the communication task between the robot and the upper-layer business system.

[0100] like Figure 1 As shown in the section on heterogeneous robots, different heterogeneous robots use their own communication protocols. The robot only needs to pass the driver configuration file and the adapter configuration file to the driver layer and adapter layer to begin access. The communication protocol field specified in the driver configuration file is `protocol`, indicating the communication protocol required by the robot. For example, `protocol: HTTP` indicates that the robot needs to load the basic driver corresponding to the HTTP protocol. Figure 2 The robot integration flowchart shown illustrates how, when a new robot needs to be integrated, it first requires its driver configuration file and adapter configuration file. The driver layer parses the driver configuration file, loads the corresponding basic driver, and builds the robot driver. The adapter layer parses the adapter configuration file and builds the robot adapter. If both are loaded successfully, robot control commands can be executed through the robot driver, and all configuration files for the corresponding robot, including the driver configuration file and adapter configuration file, will be saved in the heterogeneous robot configuration pool. If loading fails, detailed information about driver or adapter construction failure will be returned.

[0101] (2.2) Instruction Matching and Driver Method Invocation: After the robot driver receives the instruction (such as execute_route) parsed by the adapter layer, it will perform instruction matching according to the mapping relationship in the driver configuration file. Specifically, the robot driver will look up the communication protocol and operation method corresponding to the instruction according to the driver configuration file. For example, the configuration file may define the communication protocol field protocol: HTTP and the control instruction endpoint endpoint: execute_route, which means that the execute_route instruction needs to be implemented by the HTTP driver.

[0102] Next, the robot driver determines the specific method corresponding to the instruction based on the `method` field in the driver configuration file. For example, if the driver configuration file defines `method.execute_route.doPost:[url, body]`, this means the `execute_route` instruction needs to call the `doPost` method of the HTTP driver, passing the corresponding `url` and `body` parameters. The robot driver will dynamically select the corresponding base driver (HTTP driver) based on this information and call its `call` method to execute the operation.

[0103] During execution, the robot driver passes parameters from the adapter layer to the base driver. This mechanism automatically selects and executes the appropriate base driver method based on the robot instructions and the mapping in the driver configuration file, ensuring accurate robot operation. This design simplifies the instruction-to-driver mapping process, making support for different communication protocols and robots more flexible and efficient.

[0104] like Figure 1 As shown in the driver layer, the robot driver dynamic configuration module first parses the robot's driver configuration file. The configuration file defines the communication protocol field `protocol`, which explicitly indicates the specific methods bound to different communication protocols. For example, the `endpoint` field under `protocol:HTTP` might contain `execute_route`, clearly indicating that the `execute_route` command is bound to HTTP. Therefore, the robot driver determines to use the HTTP driver. Subsequently, based on the `method` field in the driver configuration file, it further locates the specific execution method of `execute_route` in the HTTP driver and its required parameters. For example, `method:execute_route:doPost:[url,body]` indicates that the `doPost` method of the HTTP driver needs to be called, and the `url` and `body` parameters need to be passed. The robot driver then calls the target method of the HTTP driver through the unified entry point `call` interface to complete the delivery.

[0105] (2.3) Parameter Hierarchy Conversion: After the adapter layer completes the semantic mapping, the robot driver typically receives a flat parameter map, while the target robot often requires structured input parameters with clear hierarchy, naming conventions, and fixed placeholders. To eliminate this structural difference, the robot driver reorganizes and nests the input parameters according to the hierarchy rules and template descriptions in the driver configuration file: including field renaming, path positioning, default value filling, constant injection, URL and Header placeholder replacement, and recursive expansion of arrays and objects. After the conversion, a tree-shaped parameter consistent with the robot interface expectation is obtained, which is then handed over to the selected base driver to initiate the call. This process does not change the business meaning, only performs "structural rearrangement and template rendering" to ensure that the robot side can parse and execute according to the agreement.

[0106] This process typically relies on parameter hierarchical mapping fields in the driver configuration file. In the driver configuration file, a `param_mapping` field is defined, specifying how to map the parameter formats of the upper-layer business system to the parameter formats required internally by the robot. This allows the robot driver to perform corresponding conversion operations based on these mapping relationships. In this way, the driver layer can flexibly adjust the parameters according to the robot's specific structural requirements.

[0107] like Figure 1 As shown in the middle driver layer, the robot driver dynamic configuration module first needs to parse the `param_mapping` field of the robot driver configuration file. This field indicates the parameter hierarchy conversion rules for different commands. For example, if the value of the `routeId` field in the `param_mapping` field defined under the command `execute_route` is `data.routeId`, it means that the `routeId` parameter of the command `execute_route` needs to be converted to `data.routeId`. After completing the hierarchy conversion, the robot driver passes the generated parameters along with the existing parameters to the unified call entry interface of the HTTP driver, triggering its internal method execution, thus closing the process of "flat parameters → robot required hierarchy" according to the path shown in the diagram.

[0108] (2.4) Log Reporting: Each time a robot initiates or completes an operation, a structured log is generated and asynchronously reported to the upper-layer business system. The log describes the key elements of the call in a unified recording format, covering the operation type, target protocol and method, robot identifier, input and output parameter summaries, execution results and time consumption information, etc., and is assigned a full-link tracing identifier to be used across the adapter layer, robot driver layer and basic driver layer. To avoid blocking the business link, log collection adopts local buffering and batch transmission. When there is network jitter, it automatically degrades to disk buffering, and retransmits after recovery to ensure that the records are not lost and do not affect the main process.

[0109] Log content includes, but is not limited to, the following dimensions: timestamp and time zone, traceId and spanId, robot ID and command name, selected protocol and target method, endpoint information such as URL path or topic name, configuration version number and method mapping version, input parameter key name and necessary parameter summary, request and response size, chain time breakdown such as queuing time, network time and robot processing time, retry count and backoff strategy, circuit breaker or rate limiting status, result code and message summary, exception type and stack trace fingerprint. Sensitive fields such as authentication tokens, signatures, personal information, and large loads will be anonymized, truncated, or hashed; only field names and lengths will be recorded when necessary to avoid leakage and excessive collection. Logs are classified as information, warnings, and errors. Debug details are only collected on demand or when the gray-scale switch is turned on to control overhead.

[0110] The log reporting mechanism not only provides reliable fault diagnosis support, but also enables transparent management of the robot operation process, enhancing the observability and maintainability of heterogeneous robot management.

[0111] (3) Semantic and parameter conversion of the adapter: Semantic and parameter conversion is performed between the instructions and parameter formats of the upper-level business system and the actual control instructions and parameter formats of the robot to ensure that the upper-level business instructions can be correctly mapped to the operations that the robot can execute. By reading the mapping relationship in the adapter configuration file, the instructions and parameters of the upper-level business system are converted into a format that the robot can recognize, and the robot's response results are restored to a format that the upper-level business system can understand. This process mainly includes three steps: instruction semantic conversion, input parameter semantic mapping, and output parameter semantic restoration.

[0112] (3.1) Command Semantic Conversion: Command semantic conversion is used to convert abstract commands from the business side into specific control commands that can be executed by the robot side, ensuring semantic consistency of the same business command across robots from different vendors. The adapter reads its own semantic mapping configuration, first standardizes the standard command names of the upper-layer business system, such as unifying capitalization, swapping camelCase and underscores, and folding aliases, and then looks up the corresponding robot-side command name according to the mapping table. The mapping priority is based on "robot-specific rules take precedence over general rules". When a command does not match the mapping, the adapter supports passing through or falling back to the default command according to the configuration, and records an alarm log to facilitate subsequent rule completion. After completing the semantic conversion, the adapter only outputs the robot-side command name and standardized parameter name. The specific communication protocol used is determined by the robot driver in subsequent steps, thus maintaining clear hierarchical responsibilities.

[0113] like Figure 1As shown in the adapter layer, the semantic conversion and parameter conversion module first parses the `convert` field in the adapter configuration file. This field is used to maintain the semantic mapping of instructions, and the `origin` field under `convert` describes the standard instruction set and naming conventions of the upper-layer business system. For example, if the adapter configuration file specifies `convert:origin:execute_route:start_route`, it means that the `execute_route` instruction of the upper-layer business system needs to be mapped to the robot's target instruction `start_route`. This ensures that the robot's final actions are completely consistent with the business requirements.

[0114] (3.2) Input Parameter Semantic Conversion: The purpose of input parameter semantic mapping is to convert the parameter names passed by the upper-layer business system to the parameter names required by the robot to perform the task. The upper-layer business system usually uses a standardized naming rule, while the robot may have its own specific naming requirements and formats. For example, the upper-layer business system may pass the parameter routeId, but the robot requires this parameter to be route_id. In the adapter configuration file, this is represented by the field mapping.input.routeId: route_id. Therefore, the adapter needs to map the parameter names of the upper-layer business system to the parameter names expected by the robot according to the mapping relationship fields defined in the adapter configuration file.

[0115] This semantic mapping ensures consistent parameter transmission between the upper-level business system and the robot, thus avoiding robot operation errors caused by mismatched parameter names or incorrect formats. In this way, the adapter can provide effective parameter conversion and adaptation between different robots, ensuring that the robot can correctly understand and execute upper-level business instructions.

[0116] like Figure 1 As shown in the adapter layer, the semantic conversion and parameter conversion module first parses the `param_mapping` field in the adapter configuration file. This field represents the parameter mapping rules for different commands. For example, the `param_mapping:execute_route: mapping:input` field indicates the input parameter mapping rules for `execute_route`. After receiving a request from the upper-layer business system, the adapter first identifies the current command as `execute_route`, then consults the adapter configuration file, converts the input parameters, and keeps the values ​​unchanged. The parameter data after this semantic mapping is then passed to the robot driver layer to ensure that the robot can accurately identify and execute operations according to its own naming conventions. This configurable parameter mapping mechanism effectively solves the compatibility problem caused by naming differences between robots from different manufacturers, realizing the automatic conversion from "standard semantics of the business layer to robot-specific semantics".

[0117] (3.3) Output Parameter Semantic Restoration: The purpose of output parameter semantic restoration is to convert the raw data returned by the robot into a format that the upper-layer business system can understand and use. The results returned by the robot after performing an operation are usually in a robot-specific format, which may include status codes, response data, or robot-specific attributes. The upper-layer business system needs these returned results to be processed and displayed in a unified and standardized form. Therefore, the adapter needs to convert the results returned by the robot into the semantics and structure expected by the upper-layer business system based on the mapping relationship fields in the adapter configuration file.

[0118] After receiving the result from the robot's drive layer, the adapter first locates the output mapping table in the adapter configuration file based on the current instruction. For example, for the `execute_route` instruction, the output node defined in the adapter configuration file describes the correspondence between the robot's returned fields and the business layer fields, such as `statusCode` → `status`, `temp` → `temperature`, and `msg` → `message`. The adapter uses this table to perform field name conversion, value normalization, and necessary semantic interpretation; for example, restoring `statusCode:200` to `status:"success"`. If the robot returns a nested structure or array, the adapter recursively applies the mapping rules, restoring the expected hierarchy and field organization from the business side layer by layer.

[0119] Furthermore, to ensure consistency between data processing in the upper-layer business system and front-end display, the adapter supports configurable type conversion and default value filling during the restoration process. For example, when the robot returns a string-type numeric field, the adapter can automatically convert it to an integer or floating-point type according to the configuration; if a field is missing or empty, a default value can be added or it can be set to empty to prevent parsing errors in the upper-layer business system. The final output data structure is consistent with the interface specifications agreed upon by the business layer, thereby achieving a closed-loop transformation from "robot language" to "business language".

[0120] Through this parameter semantic restoration mechanism, the adapter masks the differences in return formats between different robots, enabling upper-layer business systems to receive and process execution results in a unified manner. This not only improves the system's data compatibility and maintainability in multi-robot scenarios but also enhances the overall architecture's scalability and observability, ensuring that the entire process of robot operation, from instruction issuance to result feedback, is consistent, transparent, and traceable.

[0121] like Figure 1As shown in the adapter layer semantic conversion and parameter conversion module, when performing output parameter semantic restoration, the adapter layer performs field matching and semantic conversion based on the output field of `param_mapping` in the adapter configuration file. For example, specifying `execute_route:mapping:output:statusCode:status` under `param_mapping` means that the `statusCode` field returned by the robot needs to be restored to the standard `status` field required by the upper-layer business system. The processed result forms a standardized business layer response data body, allowing the upper-layer business system to directly parse and display data based on unified fields without needing to worry about the differences in return formats from different robot vendors.

[0122] (4) Dynamic selection and execution of the adapter: After receiving the upper-layer business instructions, the adapter layer dynamically selects the appropriate robot adapter based on the robot's unique identifier and executes the robot driving operation. This process not only ensures the correct execution of robot instructions but also dynamically adapts to the needs of different robots and communication protocols. This process includes three key steps: adapter selection and matching, robot driving invocation and execution, and execution result feedback and business layer response.

[0123] (4.1) Adapter Selection and Matching: After receiving instructions from the upper-layer business system, the adapter layer first locates and selects the corresponding robot adapter based on the robot's unique identifier. Each robot has an independent adapter, and the adapter selection depends on the robot's identifier and its communication protocol. The adapter layer reads the adapter configuration file, identifies the robot's communication protocol (such as HTTP, MQTT, WebSocket, etc.), and then selects and loads the corresponding robot adapter based on the protocol type. In this way, robot adapters can be flexibly selected and configured, ensuring seamless integration of instructions and data between the robot and the upper-layer business system.

[0124] For example, when a robot's unique identifier is passed to the adapter layer, the adapter layer looks up the corresponding entry in the adapter configuration file to determine the communication protocol and required drive method used by the robot, and then matches the correct robot adapter for processing. This process ensures the robot's independence and flexible selection of communication protocols, avoiding the complexity of hard coding and manual configuration.

[0125] like Figure 1As shown, the heterogeneous robot configuration pool manages the drivers, adapters, and corresponding configuration files for all robots, including cameras, track robots, wall-climbing robots, and drones. All connected robots store their drivers and adapters in this unified pool. The command dispatcher within the dynamic selection and execution module of the adapter layer receives upper-layer business commands and routes them to the corresponding adapter in the heterogeneous robot configuration pool based on the robot ID. The adapter for a specific robot then calls the robot driver to execute the specific task.

[0126] (4.2) Robot driver invocation and execution: All robot adapters provide a unified call entry point handleCommand interface. The upper-layer business system issues commands through the handleCommand interface. After receiving the handleCommand request from the upper-layer business, the adapter first parses the command content and performs semantic conversion of control commands and parameter formats according to the information in the adapter configuration file, and dynamically selects the robot driver corresponding to the command.

[0127] Specifically, when the upper layer calls the `handleCommand` interface, the adapter extracts the relevant operations (such as `execute_route`) and required parameters from the instruction, and then looks up the corresponding communication protocol and driver method according to the adapter configuration file. The adapter finds the robot driver associated with the instruction by reading the adapter configuration file, and then calls the corresponding driver's method. In this way, the upper-layer business system only needs to focus on the transmission of instructions and parameters, without needing to handle driver selection and method invocation; the adapter automatically completes these operations based on the instruction content and the adapter configuration file.

[0128] This mechanism makes calling the interface of the upper-layer business system extremely simple. Only one call to the handleCommand interface is needed to complete the entire process from instruction parsing and driver matching to method execution. The adapter is responsible for automatically routing instructions, loading drivers, and passing parameters according to the adapter configuration file, thereby shielding the differences between different robot drivers.

[0129] like Figure 1 As shown, the adapter layer's dynamic selection and execution module provides a unified call entry point, the `handleCommand` interface, for all robot adapters. Upper-layer business systems only need to call this interface and pass the corresponding parameters. The adapter layer will then select the specific robot adapter to execute the task based on the parameters passed from the upper-layer business system.

[0130] (4.3) Execution result feedback and business layer response: After the robot driver completes the task execution, it will return the execution result (including status, data, error information, etc.) to the robot adapter. After receiving the result, the adapter will first format and semantically restore the raw data returned by the robot according to the output mapping rules in the configuration file, and uniformly convert the robot-specific field names, status codes and data structures into a format that the upper-layer business system can recognize.

[0131] During the feedback phase, the adapter also includes execution metadata such as robot ID, execution method, operation time, and driver protocol type. This information not only facilitates logging and performance analysis for the upper-layer business system but also supports subsequent scheduling optimization and anomaly tracking. Once the upper-layer business system receives the standardized results returned by the adapter, it can directly perform subsequent logical processing based on the result status, such as updating the interface status, issuing anomaly alarms, persisting data, or retrying tasks, thereby achieving seamless integration between robot execution and business logic.

[0132] Through this execution result feedback mechanism, this invention constructs a closed-loop channel from the issuance of business instructions and robot-driven execution to the return of results, ensuring the transparency and traceability of the entire robot operation process. The adapter plays a crucial "result translator" role in this process, enabling the execution results of robots from different protocols and manufacturers to be uniformly recognized and processed by the upper-layer business system, significantly improving the system's stability and maintenance efficiency in multi-robot scenarios.

[0133] Obviously, those skilled in the art should understand that the steps of the heterogeneous robot access method based on dynamic configuration drive described in the above embodiments of the present invention can be implemented using general-purpose computing devices. These devices can be centrally deployed on a single device or distributed across a network system composed of multiple computing devices. Optionally, the above-mentioned functional modules and processing flows can be implemented using computer-executable program code and stored in a readable storage medium, and executed by a central processing unit or edge computing unit. Depending on the specific application scenario, some steps in the method can be executed in different orders, or implemented as independent integrated circuit units, or multiple functional modules can be integrated into an integrated hardware module for physical encapsulation and scheduling support. Therefore, the embodiments of the present invention are not limited to any specific combination of software structure, hardware platform, or system architecture. Any equivalent transformations and functional extensions made within the spirit and essence of the present invention should be covered within the protection scope of the present invention.

Claims

1. A method for accessing heterogeneous robots based on dynamic configuration, characterized in that, Includes the following: (1) Building the basic driver: Construct pluggable basic drivers, encapsulate the communication protocol between heterogeneous robots and upper-level business systems, and implement the corresponding operation method according to the communication protocol type; (2) Dynamic configuration of robot drive: Read the drive configuration file, dynamically select and combine different basic drives according to the robot's communication protocol and operation requirements, generate robot drive, and complete robot operation tasks; the robot drive is used to execute robot tasks and report log information during the execution process to the upper-level business system; (3) Semantic conversion and parameter conversion of the adapter: The adapter completes the semantic conversion between the upper-layer business instructions and the robot control instructions according to the adapter configuration file, and maps the parameter format of the upper-layer business system to the parameter format required by the robot control instructions; After the robot finishes its execution, the adapter converts the parameter format returned by the robot into a parameter format that the upper-layer business system can understand. (4) Dynamic selection and execution of the adapter: During the task execution process, the upper-level business system finds and selects the corresponding robot adapter through the robot's unique identifier. The adapter calls the robot driver according to the upper-level business instructions, executes the robot control operation, and feeds back the execution result to the upper-level business system.

2. The heterogeneous robot access method based on dynamic configuration driving according to claim 1, characterized in that, The basic drivers include HTTP driver, MQTT driver and WebSocket driver, which support communication with different heterogeneous robots.

3. The heterogeneous robot access method based on dynamic configuration driving according to claim 1, characterized in that, The specific implementation steps for building the basic driver (1) are as follows: Step 1.1, Driver Utility Class Design: A pluggable basic driver architecture was designed; the basic driver is a driver class; each basic driver encapsulates the communication logic between different communication protocols and the robot, and provides a unified call entry interface; the pluggable design is implemented through a combination of interfaces and abstract classes in the Java language; in the pluggable basic driver architecture, the basic driver implements a unified entry interface IDeviceDriver, which defines the unified calling method of the basic driver, that is, the abstract implementation of the unified call entry interface call; the basic driver implements the operations set by different communication protocols by inheriting the IDeviceDriver interface; Through the dependency injection mechanism, the corresponding basic driver is dynamically selected and loaded at runtime based on the driver configuration file, so that the access of a new protocol only requires creating a new basic driver and updating the configuration file. Step 1.2, Driver method implementation, including: (1a) HTTP driver methods: Define methods for calling POST request types, sending data and obtaining response results, and define methods for calling GET request types, sending data and obtaining response results; (1b) MQTT-driven methods: Define methods for publishing data to a specified MQTT topic and ensuring timely message delivery; define methods for subscribing to multiple topics and receiving messages from the robot in real time; (1c) WebSocket driver methods: Define methods for establishing a WebSocket connection with the robot and providing support for full-duplex communication; define methods for sending messages and methods for receiving messages returned from the robot; (1d) SSE-driven method: Define the method responsible for establishing a one-way connection with the server and receiving event streams from the server in real time; define the method for processing event data and passing it to the upper-layer business system for processing; Step 1.3, Unified Method Invocation: All base drivers implement a unified call entry interface, `call`. The `call` interface receives two parameters: the method name `method` and the parameters `params` passed to the method. Based on these two parameters, the `call` interface dynamically determines the method to invoke in the base driver. When the `call` interface is invoked, it first searches for the corresponding method in the base driver of the current communication protocol based on the passed method name `method`. Through reflection, the `call` interface dynamically identifies and executes the corresponding method, and extracts the necessary parameters from `params` as input to pass to the method.

4. The heterogeneous robot access method based on dynamic configuration driving according to claim 1, characterized in that, The dynamic configuration of robot drive (2) refers to the process of dynamically selecting and combining basic drivers and generating robot drivers based on the robot's communication protocol and operational requirements after reading the robot's driver configuration file. The dynamic configuration process of robot drive is achieved through a three-step method of "driver selection + instruction matching + parameter conversion". The dynamic configuration of robot drive (2) includes the following steps: Step 2.1, Configuration File Parsing and Driver Selection: By parsing the robot's driver configuration file, the communication protocols, operational requirements, and related parameters defined therein are extracted; based on the driver configuration file, basic drivers of different communication protocols are loaded and combined; the robot defines the corresponding protocols in the configuration file according to the communication requirements, ensuring that the basic drivers can be loaded as needed, thereby completing the communication tasks between the robot and the upper-level business system. Step 2.2, Instruction Matching and Driver Method Invocation: After the robot driver receives the instruction parsed by the adapter layer, it will match the instruction according to the mapping relationship in the driver configuration file; the robot driver will look up the communication protocol and operation method corresponding to the instruction according to the driver configuration file; then, the robot driver will determine the method corresponding to the instruction according to the method field in the configuration file; and call the call interface to execute the operation; during the execution process, the robot driver will pass the parameters passed by the adapter layer to the base driver. Step 2.3, Parameter Hierarchy Conversion: Based on the parameter hierarchy mapping relationship defined in the driver configuration file, the robot driver converts the flattened parameters passed from the upper-layer business system into a nested hierarchical structure expected by the robot, according to the needs of each robot; the robot driver reads the parameter mapping relationship in the driver configuration file, traverses the incoming parameters, and converts the parameters into a format that the robot can recognize as needed. Step 2.4, Log Reporting: Each time the robot drives a task, an operation log is recorded, including the operation type, parameters used, operation result, and operation time; the log information will be reported to the upper-level business system.

5. The heterogeneous robot access method based on dynamic configuration driving according to claim 1, characterized in that, The semantic conversion and parameter conversion of the adapter (3) refers to the semantic and parameter conversion between the instructions and parameter formats of the upper-layer business system and the actual control instructions and parameter formats of the robot; the implementation process of the semantic conversion and parameter conversion of the adapter includes the following steps: Step 3.1, Instruction semantic conversion: The adapter converts the instructions from the upper-layer business system into the actual control instructions required by the robot by consulting the control instruction mapping relationship in the adapter configuration file; Step 3.2, Input Parameter Semantic Mapping: The adapter maps the parameter names of the upper-layer business system to the names expected by the robot by consulting the input parameter format mapping relationship in the adapter configuration file; Step 3.3, Output Parameter Semantic Restoration: The adapter transforms the results returned by the robot into the semantics and structure expected by the upper-layer business system by consulting the output parameter format mapping relationship in the adapter configuration file.

6. The heterogeneous robot access method based on dynamic configuration driving according to claim 1, characterized in that, The dynamic selection and execution of the adapter (4) refers to the adapter layer dynamically selecting the adapter of a specific robot and executing the robot drive operation based on the robot's unique identifier after receiving the upper-layer business instruction. This includes the following implementation steps: Step 4.1, Adapter Selection and Matching: After receiving the upper-layer business instruction, the adapter layer first searches for and selects the corresponding robot adapter based on the robot's unique identifier, reads the adapter configuration file, identifies the robot's communication protocol, calls the specific robot driver, and executes the corresponding control method. Step 4.2, Robot driver invocation and execution: All robot adapters provide a unified call entry point handleCommand interface. The upper-layer business system issues commands through the handleCommand interface. After receiving the handleCommand request from the upper-layer business system, the adapter first parses the command content and performs semantic conversion of control commands and parameter formats according to the information in the adapter configuration file, and dynamically selects the robot driver corresponding to the command. Step 4.3, Execution Result Feedback and Business Layer Response: After the robot operation is completed, the robot driver will return the execution result to the adapter. The adapter will process the data returned by the robot and the adapter configuration file, and then feed the result back to the upper-layer business system.

7. A heterogeneous robot access system based on dynamic configuration drive, characterized in that, Includes the following modules: Basic Driver Setup Module: This module encapsulates the communication protocol between heterogeneous robots and upper-layer business systems by constructing pluggable basic drivers; each basic driver implements the corresponding operation method according to different communication protocols. Robot drive dynamic configuration module: This module dynamically selects and loads the basic driver according to the robot's driver configuration file, thereby generating the corresponding robot driver and executing the robot operation task; By parsing the communication protocol and operation requirements in the driver configuration file, the basic driver is automatically selected, and the parameter level is converted according to the actual needs of the robot; the dynamic configuration module of the robot driver will also report the data during the execution process to the upper-level business system. Semantic conversion and parameter conversion module: This module maps and converts the semantics and parameters between the instructions of the upper-level business system and the actual control instructions of the robot through an adapter; according to the mapping relationship in the adapter configuration file, it converts the high-level instructions of the upper-level business system into control instructions that the robot can execute, and maps the parameter format of the upper-level business system to the parameter format required by the robot. Dynamic Selection and Execution Module: This module locates and selects the corresponding robot adapter based on the robot's unique identifier; Each robot has a unique adapter, which provides a unified entry point for receiving upper-level business instructions and passing them to the robot driver. The adapter calls the robot driver through the business instructions, executes the corresponding operations, and returns the results to the upper-level business system.

8. A computer device, characterized in that: The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the heterogeneous robot access method based on dynamic configuration drive as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that: When the computer program / instruction is executed by the processor, it implements the steps of the heterogeneous robot access method based on dynamic configuration drive as described in any one of claims 1-6.

Images