A method and system for developing software and hardware of a patrol robot

Abstract

This application relates to the field of rail transit technology, and in particular to a software and hardware development method and system for an inspection robot. The method includes: based on user-inputted task scenario requirements, calling multiple 3D hardware models from a physical modular hardware library to obtain a 3D simulation robot corresponding to the task requirements; based on the 3D simulation robot, the task scenario requirements, and the physical attributes of each 3D hardware model in the 3D simulation robot, calling multiple standard functional nodes from a pre-established node library to construct a task logic flowchart; and based on the task logic flowchart, performing operational simulation and logic verification on the 3D simulation robot to obtain a task execution strategy; and based on the task execution strategy, compiling and packaging the task logic flowchart to obtain executable code for the user to drive the physical robot to perform operations. This significantly improves the development efficiency of inspection robots while lowering the development threshold.

Description

Technical Field

[0001] This application relates to the field of rail transit technology, and in particular to a software and hardware development method and system for an inspection robot. Background Technology

[0002] The rapid development of robotics technology has driven its widespread application in the field of intelligent operation and maintenance of rail transit. The complex and ever-changing maintenance environment of rail transit places extremely high demands on the reliability, adaptability, and development efficiency of inspection robots. However, existing robot development systems suffer from significant bottlenecks in hardware and software collaboration, making it difficult to meet the rapid prototyping and industrial-grade reliability requirements of the rail transit sector.

[0003] At the software level, open-source robot operating systems (such as ROS and ROS2) provide communication middleware and algorithm libraries, promoting the standardization of software development. However, they only address upper-level framework issues and do not involve the rapid construction and integration of hardware. Developers still need to select and adapt physical components such as sensors and actuators themselves, and each new hardware requires the writing of a dedicated driver node, making the software-hardware integration process cumbersome and requiring a high level of expertise. At the hardware level, modular robot kits (such as Makeblock and RoboMaster) provide standardized modules through unified interfaces, lowering the integration threshold. However, their design is geared towards education and entertainment scenarios, compromising on material strength, connection reliability, electromagnetic compatibility, and environmental protection levels. They cannot meet the long-term stable operation requirements of harsh environments such as vibration, oil contamination, and electromagnetic interference in rail transit maintenance workshops. At the industrial application level, mature industrial robot systems represented by ABB and KUKA have high reliability, but they adopt closed or semi-closed architectures with deep software and hardware coupling. They only provide limited high-level application interfaces, and customized development is limited by vendor interfaces and expensive technical services. Furthermore, their fixed form makes it difficult to develop innovative configurations that adapt to unstructured terrain. The Robots as a Service (RaaS) model provides complete solutions rather than development tools, and cannot support users' independent rapid prototyping development.

[0004] In summary, the existing development model for rail transit inspection robots is characterized by a disconnect between the software framework and hardware modules. The lack of a standardized hardware resource library that is adapted to harsh industrial environments and has a unified interface leads to low efficiency in software and hardware collaborative development. Consequently, the development of inspection robots for complex rail transit scenarios faces high costs, long cycles, and high barriers to entry. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] In view of the above-mentioned shortcomings and deficiencies of the prior art, this application provides a software and hardware development method and system for inspection robots, which solves the technical problems of high cost, long cycle and high threshold faced in the development of inspection robots for complex rail transit scenarios.

[0007] (II) Technical Solution

[0008] To achieve the above objectives, the main technical solutions adopted in this application include:

[0009] In a first aspect, embodiments of this application provide a software and hardware development method for an inspection robot, applied in the field of rail transit, comprising: based on user-inputted task scenario requirements, calling multiple three-dimensional hardware models from a pre-established physical modular hardware library to perform three-dimensional modeling of the task scenario requirements, thereby obtaining a three-dimensional simulation robot corresponding to the task requirements; wherein each three-dimensional hardware model has corresponding physical attributes; based on the three-dimensional simulation robot and the task scenario requirements, and the physical attributes corresponding to each three-dimensional hardware model in the three-dimensional simulation robot, calling multiple standard functional nodes from a pre-established node library to construct a task logic flowchart corresponding to the three-dimensional simulation robot, and performing operational simulation and logic verification on the three-dimensional simulation robot based on the task logic flowchart to obtain a task execution strategy; wherein the task logic flowchart is a data flow diagram that topologically connects all standard functional nodes in a logical order through graphical connections; based on the task execution strategy, compiling and packaging the task logic flowchart to obtain corresponding executable code, and distributing the executable code to the physical robot to drive the physical robot to perform the operation corresponding to the task scenario requirements; the physical robot is a physical robot pre-established based on the task scenario requirements, and has the same architecture as the three-dimensional simulation robot.

[0010] Optionally, the physical modular hardware library is established based on the following steps: Based on user-inputted standard functional requirements, the rail transit inspection robot is functionally decoupled to divide it into multiple standard components, each with corresponding component attributes; the standard functional requirements are those necessary for the normal operation of the rail transit inspection robot; three-dimensional geometric modeling is performed on each standard component to generate a corresponding three-dimensional hardware model, and the physical interface and interface protocol of each three-dimensional hardware model are configured, with all three-dimensional hardware models having consistent physical interfaces and interface protocols; each three-dimensional hardware model has corresponding hardware attributes, and these physical attributes are obtained based on the corresponding component attributes; based on each three-dimensional hardware model and its corresponding physical attributes, a hardware description file is generated for each three-dimensional hardware model; the physical attributes include hardware attributes, physical interfaces, and interface protocols; based on the hardware description file corresponding to each three-dimensional hardware model, a physical modular hardware library is constructed; each hardware description file in the physical modular hardware library has a corresponding index.

[0011] Optionally, based on the task scenario requirements input by the user, multiple 3D hardware models are called from a pre-established physical modular hardware library to perform 3D modeling of the task scenario requirements and obtain a 3D simulation robot corresponding to the task requirements. This includes: extracting features from the task scenario requirements input by the user to obtain corresponding scene feature vectors, and filtering all 3D hardware models in the physical modular hardware library based on the scene feature vectors to obtain a set of candidate components; selecting multiple 3D hardware models from the set of candidate components based on a first scheduling instruction input by the user, and rigidly assembling the selected 3D hardware models based on a second scheduling instruction input by the user to obtain a 3D simulation robot corresponding to the task requirements.

[0012] Optionally, based on the task scenario requirements input by the user, multiple 3D hardware models are called from a pre-established physical modular hardware library to perform 3D modeling of the task scenario requirements and obtain a 3D simulation robot corresponding to the task requirements. The method further includes: after obtaining the 3D simulation robot corresponding to the task requirements, establishing a dynamic model and a kinematic model of the 3D simulation robot based on the physical properties of each 3D hardware model in the 3D simulation robot, performing kinematic simulation verification and dynamic simulation verification on the 3D simulation robot, obtaining the corresponding simulation verification results, and optimizing and adjusting the 3D simulation robot based on the verification results.

[0013] Optionally, the node library is established based on the following steps: obtaining all standard functional nodes in the general operation process based on user input; the general operation process includes all operation processes during the normal operation of the rail transit inspection robot; and obtaining the interface definition and configurable parameter set corresponding to each standard functional node based on the node configuration file input by the user; establishing a node description file corresponding to each standard functional node based on each standard functional node and the corresponding interface definition and configurable parameter set; and constructing a node library based on the node description file corresponding to each standard functional node; wherein each standard functional node in the node library has a corresponding index.

[0014] Optionally, based on the requirements of the 3D simulation robot and the task scenario, as well as the physical attributes corresponding to each 3D hardware model in the 3D simulation robot, multiple standard functional nodes are called from a pre-established node library to construct a task logic flowchart corresponding to the 3D simulation robot. This includes: obtaining the corresponding task execution sequence based on the task scenario requirements, and retrieving and calling multiple standard functional nodes from the node library based on the task execution sequence; logically connecting and configuring the parameters of all called standard functional nodes based on the 3D simulation robot to construct a task logic flowchart describing the entire cycle of robot operation; the task logic flowchart is used to define the closed-loop control logic of the 3D simulation robot from environmental perception to actuator action.

[0015] Optionally, based on the task logic flowchart, the 3D simulation robot is subjected to operational simulation and logic verification to obtain a task execution strategy. This includes: loading the task logic flowchart into a pre-set simulation engine to perform operational simulation on the 3D simulation robot to obtain operational simulation results; the operational simulation results include the logic verification results obtained by performing logic verification on the operational status of each monitoring node of the 3D simulation robot in real time during the operational simulation; and constructing a task execution strategy based on the operational simulation results to guide the static configuration parameters of the 3D simulation robot task.

[0016] Optionally, based on the task execution strategy, the task logic flowchart is compiled and packaged to obtain the corresponding executable code, including: performing structural analysis on the task logic flowchart to extract all standard functional nodes in the task logic flowchart and the connection relationships between each standard functional node; constructing a data flow dependency graph based on all standard functional nodes in the task logic flowchart and the connection relationships between each standard functional node; constructing an intermediate representation file describing the operation logic of the 3D simulation robot based on the data flow dependency graph and the task execution strategy; traversing all standard functional nodes in the task logic flowchart based on the intermediate representation file to retrieve the code fragment corresponding to each standard functional node in the task logic flowchart from a pre-established code template library; and statically configuring the task based on the task execution strategy. The parameter injection task logic flowchart includes code snippets corresponding to each standard functional node. Placeholders for each code snippet are configured, and based on all configured code snippets, instantiated functional code tailored to the task scenario requirements is generated. Based on the task logic flowchart, the instantiated functional code is logically assembled to generate the corresponding main program file. Based on the data flow dependency graph, a project configuration file corresponding to the main program file is generated. The project configuration file represents the call paths of external resources required to execute the main program file. Based on the project configuration file and a pre-set compiler, the main program file and the external resources required to execute the main program file are compiled to obtain an executable file. The executable file is then packaged according to a pre-set directory structure to obtain a deployable image, which is the executable code.

[0017] Secondly, embodiments of this application provide a software and hardware development system for an inspection robot. The system is applied in the rail transit field and includes: a simulation model construction module, used to call multiple 3D hardware models from a pre-established physical modular hardware library based on user-inputted task scenario requirements to perform 3D modeling of the task scenario requirements and obtain a 3D simulation robot corresponding to the task requirements; wherein each 3D hardware model has corresponding physical attributes; and a task logic construction module, used to call multiple standard functional nodes from a pre-established node library based on the 3D simulation robot, the task scenario requirements, and the physical attributes corresponding to each 3D hardware model in the 3D simulation robot to construct the 3D simulation robot. A task logic flowchart corresponding to a human is generated, and based on the task logic flowchart, the 3D simulation robot is run for simulation and logic verification to obtain a task execution strategy. The task logic flowchart is a data flow diagram that connects all standard functional nodes in a logical order using graphical connections. A task code distribution module is used to compile and package the task logic flowchart based on the task execution strategy to obtain corresponding executable code, and then distribute the executable code to the physical robot to drive it to perform tasks corresponding to the task scenario requirements. The physical robot is a pre-built entity robot based on the task scenario requirements and has the same architecture as the 3D simulation robot.

[0018] Optionally, the system further includes: a remote cloud platform; the remote cloud platform is used to perform synchronous simulation operations based on a 3D simulation robot and a task logic flowchart when the physical robot performs tasks corresponding to the task scenario requirements based on executable code; to acquire real-time physical operation data during the physical robot's operation and real-time simulation operation data during the synchronous simulation operation of the 3D simulation robot; and to determine whether to send an emergency control command to the physical robot based on the real-time physical operation data and the real-time simulation operation data.

[0019] (III) Beneficial Effects

[0020] This application provides a software and hardware development method for an inspection robot. By calling 3D hardware models from a physical modular hardware library, a 3D simulation robot adapted to the task scenario can be quickly constructed, achieving hardware configuration reuse and rapid adaptation. Furthermore, by building a graphical task logic flowchart based on a node library and conducting simulation verification, software and hardware compatibility issues can be identified in advance, reducing physical debugging costs and iteration cycles. Automatic compilation to generate executable code and its distribution to physical robots with the same architecture effectively improves development efficiency and lowers the development threshold. Attached Figure Description

[0021] Figure 1A schematic diagram of the software and hardware development method for an inspection robot provided in an embodiment of this application;

[0022] Figure 2 A schematic diagram of the software and hardware development system architecture for an inspection robot provided in this application embodiment;

[0023] Figure 3 This application provides examples of standardized hardware interfaces and modular assembly.

[0024] Figure 4 This is a schematic diagram of the layered decoupling process provided in an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of cloud collaboration provided for an embodiment of this application. Detailed Implementation

[0026] To better explain and facilitate understanding of this application, the following detailed description of the application is provided in conjunction with the accompanying drawings and specific embodiments.

[0027] To better understand the above technical solutions, exemplary embodiments of this application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application can be understood more clearly and thoroughly, and that the scope of this application can be fully conveyed to those skilled in the art.

[0028] This application provides a software and hardware development method for an inspection robot, which is applied in the field of rail transit. The method flow is as follows: Figure 1 As shown, it includes:

[0029] S1. Based on the task scenario requirements input by the user, multiple 3D hardware models are called from a pre-established physical modular hardware library to perform 3D modeling of the task scenario requirements and obtain a 3D simulation robot corresponding to the task requirements; each 3D hardware model has corresponding physical properties.

[0030] S2. Based on the requirements of the 3D simulation robot and the task scenario, as well as the physical attributes of each 3D hardware model in the 3D simulation robot, multiple standard functional nodes are called from a pre-established node library to construct the task logic flowchart corresponding to the 3D simulation robot. Based on the task logic flowchart, the 3D simulation robot is run for simulation and logic verification to obtain the task execution strategy. The task logic flowchart is a data flow diagram that connects all standard functional nodes in a logical order through graphical connections.

[0031] S3. Based on the task execution strategy, the task logic flowchart is compiled and packaged to obtain the corresponding executable code, and the executable code is sent to the physical robot to drive the physical robot to perform the tasks required by the task scenario. The physical robot is a physical robot that is pre-built based on the task scenario requirements and has the same architecture as the 3D simulation robot.

[0032] This embodiment provides a software and hardware development method for an inspection robot, which significantly improves the development efficiency of the inspection robot while lowering the development threshold.

[0033] Optionally, in one specific embodiment, the physical modular hardware library is built based on the following steps:

[0034] Based on user-inputted standard functional requirements, the rail transit inspection robot undergoes functional decoupling to divide it into multiple standard components, each with corresponding component attributes. The standard functional requirements are those necessary for the normal operation of the rail transit inspection robot. Three-dimensional geometric modeling is performed on each standard component to generate a corresponding three-dimensional hardware model. The physical interface and interface protocol of each three-dimensional hardware model are configured, and all three-dimensional hardware models have consistent physical interfaces and interface protocols. Each three-dimensional hardware model has corresponding hardware attributes, and these physical attributes are obtained based on the corresponding component attributes. Based on each three-dimensional hardware model and its corresponding physical attributes, a hardware description file is generated for each three-dimensional hardware model. Physical attributes include hardware properties, physical interfaces, and interface protocols. Based on the hardware description files for each three-dimensional hardware model, a physical modular hardware library is constructed. Each hardware description file in the physical modular hardware library has a corresponding index.

[0035] Specifically, the standardized hardware interface and modular assembly diagram are as follows: Figure 3 As shown, the functional decoupling framework is as follows: Figure 4As shown, the physical modular hardware library is a series of core hardware libraries with decoupled functions and unified interfaces provided in this embodiment. It includes at least: computing and control modules, such as edge AI computing modules equipped with high-performance SoCs and microcontroller modules responsible for real-time motor control; drive and execution modules, covering servo joints, hub motors, and linear modules with various torque and speed levels; sensing modules, such as integrated vision modules with optical and processing circuits, LiDAR, force / torque sensors, and environmental sensors; and energy and structure modules, including smart battery packs and standardized connecting rods and mounting plates. All modules are designed for reliability according to the vibration, dust, temperature, and humidity requirements of the rail transit environment. Furthermore, all modules in the physical modular hardware library use a three-in-one standard interface and a plug-and-play protocol, meaning that each module is configured with a unified physical interface predefined in this embodiment. This interface inherits a mechanical locking mechanism to ensure a stable and vibration-resistant connection; high-current power contacts to directly power each module; and a high-speed data communication bus (such as a real-time bus based on Ethernet). At the protocol layer, each module broadcasts its identity and functional description file to the bus after power-on. The main controller can automatically identify, address, and integrate new modules, realizing "plug and play" hardware and greatly simplifying the complexity of integration and expansion.

[0036] This embodiment uses a vehicle undercarriage inspection robot as an example to detail the steps for establishing a physical modular hardware library. The robot is used for daily inspections of the undercarriages of rail transit vehicles and needs to possess core functions such as autonomous walking, visual inspection, and data processing. Through functional decoupling, standardized modeling, hardware description file generation, and modular library construction, rapid selection and configuration of hardware modules are achieved.

[0037] To meet the actual operational needs of the under-vehicle inspection robot, the standard functional requirements for its normal operation are defined as follows: motion control function, enabling the robot to navigate and avoid obstacles autonomously in the narrow space under the vehicle, requiring a walking speed of 0.2~0.8m / s and a positioning accuracy better than ±10mm; visual inspection function, performing image acquisition and analysis of key components under the vehicle, requiring support for multi-angle camera deployment with a coverage rate of ≥95%; data processing function, processing visual data in real time and completing defect identification, requiring a single-frame image processing latency of <200ms; environmental perception function, perceiving surrounding obstacles and personnel to ensure operational safety; energy management function, providing continuous operation capability, with a single charge providing a battery life of ≥4 hours; and communication interaction function, uploading data and receiving commands with the backend. Based on the aforementioned standard functional requirements, a top-down functional hierarchy approach is adopted, dividing the robot into four functional domains: Motion domain: mobile chassis drive, steering control, and braking and holding, with typical components being servo joint modules and hub motor modules; Perception domain: visual acquisition, environmental perception, and force / torque detection, with typical components being vision modules, LiDAR, and force sensors; Decision domain: data calculation, motion planning, and status monitoring, with typical components being AI computing units and microcontroller units; Execution domain: energy supply, structural adjustment, and module connection, with typical components being battery modules, structural connectors, and mounting plates. After functional decoupling and standard component partitioning, the standard component partitioning and attribute definition are performed. Specific steps include: taking the servo joint module in the motion domain as an example, this module exists as an independent standard component after functional decoupling. Its component attributes include: functional parameters: rated torque 15 N·m, peak torque 45 N·m, rated speed 60 rpm, reduction ratio 1:50; performance indicators: position accuracy ±0.05°, repeatability ±0.02°, response time ≤20 ms; environmental adaptability: protection level IP67, operating temperature -20℃~+55℃, vibration resistance conforming to ISO 10816-3; physical parameters: outer diameter 80 mm, length 120 mm, weight 1.2 kg; electrical parameters: rated voltage 48VDC, rated current 5A, communication interface CAN / Ethernet dual redundancy. These component attributes serve as the baseline data for subsequent 3D modeling and hardware description file generation.

[0038] Secondly, three-dimensional geometric modeling and standardization are performed, namely:

[0039] First, taking the servo joint module as an example, its three-dimensional geometric modeling process includes:

[0040] Geometric feature extraction: Based on the physical parameters in the component attributes, the basic geometric features of the module are established, including the cylindrical shell, flange mounting surface, output shaft, etc. Parametric design is adopted in the 3D modeling software, with the shell diameter of 80mm, length of 120mm, and flange thickness of 12mm all set as adjustable parameters. Internal structure modeling: According to the rated torque and reduction ratio parameters, the internal reduction mechanism, bearing arrangement, encoder installation position, etc. are designed to ensure that the model accurately reflects the physical structure. Lightweight processing: While ensuring structural strength, the non-load-bearing areas are hollowed out to reduce the module weight to 1.2kg. Visual optimization: Visual elements such as surface markings, brand logo, and installation instructions are added to generate the final mesh model (STL format) and solid model (STEP format). Secondly, to achieve plug-and-play functionality between modules, all 3D hardware models adopt a unified three-in-one standard interface design: a mechanical locking mechanism, including a positioning pin (foolproof design to ensure correct insertion direction), a locking buckle (press-to-release, locking force ≥500N), and a threaded collar (auxiliary locking, preventing loosening), with a positioning pin diameter of 6mm and a buckle travel of 8mm; high-current power contacts, using gold-plated contact design, rated current 10A (peak 30A), contact spacing 2.5mm, a total of 4 pins (V+, V-, FG, NC), and self-cleaning function; and a high-speed data communication contact array, including a CAN bus interface (2 pins, 120Ω terminating resistor built-in) and a Gigabit Ethernet interface (8 pins, supporting PoE power supply), supporting dual redundant communication. The physical dimensions, positional tolerances, and mounting hole positions of the interfaces are all designed according to a unified standard to ensure physical compatibility between different modules. Finally, the interface protocol is designed so that after the module is powered on, the integration is automatically completed through the interface protocol: In the identity broadcast phase, the module is powered on and broadcasts basic information such as device ID (e.g., “SERVO-ACT-15NM-v2.1”), function type (“servo joint”), and firmware version to the bus; In the automatic identification phase, the main controller receives the broadcast information, assigns a network address (e.g., NODE-007) to the new module, and records it in the device list; In the function negotiation phase, the main controller reads the module’s hardware description file and completes parameter matching and function enabling.

[0041] After completing functional decoupling and standard component partitioning, as well as 3D geometric modeling and interface standardization, hardware description files (HDFs) are generated in JSON format. These HDFs are automatically generated by the modeling software, using API interfaces to write component attributes, modeling parameters, and interface configurations into the JSON file. Each HDF file uses a module ID as a unique identifier and generates a corresponding MD5 checksum to ensure file integrity. Following the generation of the hardware description files, a physical modular hardware library is constructed. This library employs a hierarchical, tree-like structure and a multi-dimensional indexing mechanism to support flexible searching. Ultimately, a visual interface allows users to filter target modules by dimension and return a list of matching hardware description files. Selecting a module allows users to directly drag and drop its 3D model into the virtual design environment for rapid robot configuration building.

[0042] This embodiment demonstrates a method for establishing a physically modular hardware library, forming a complete technical chain: standard functional requirements → functional decoupling and component partitioning → 3D geometric modeling and interface standardization → hardware description file generation → modular hardware library construction. This method transforms the hardware selection for rail transit inspection robots from customized development to standardized combination, significantly shortening the R&D cycle, while ensuring compatibility and reliability between modules through a unified interface protocol.

[0043] Optionally, in one specific embodiment, based on the task scenario requirements input by the user, multiple 3D hardware models are called from a pre-established physical modular hardware library to perform 3D modeling of the task scenario requirements and obtain a 3D simulation robot corresponding to the task requirements. This includes: extracting features from the task scenario requirements input by the user to obtain corresponding scene feature vectors, and filtering all 3D hardware models in the physical modular hardware library based on the scene feature vectors to obtain a set of candidate components; filtering multiple 3D hardware models from the set of candidate components based on a first scheduling instruction input by the user, and rigidly assembling the filtered 3D hardware models based on a second scheduling instruction input by the user to obtain a 3D simulation robot corresponding to the task requirements.

[0044] Furthermore, based on the user-inputted task scenario requirements, multiple 3D hardware models are called from a pre-established physical modular hardware library to perform 3D modeling of the task scenario requirements, thereby obtaining a 3D simulation robot corresponding to the task requirements. This also includes: after obtaining the 3D simulation robot corresponding to the task requirements, establishing a dynamic model and kinematic model of the 3D simulation robot based on the physical properties of each 3D hardware model in the 3D simulation robot, to perform kinematic simulation verification and dynamic simulation verification of the 3D simulation robot, obtain the corresponding simulation verification results, and optimize and adjust the 3D simulation robot based on the verification results.

[0045] Specifically, users input task scenario requirements through a visual interactive interface. These input formats include, but are not limited to: natural language text descriptions (e.g., "A mobile robot is needed for detecting cracks in the walls of subway tunnels"), parameterized input interfaces (using sliders and input boxes to set parameters such as working radius, load capacity, and protection level), and preset scenario template selections (pre-set templates of typical operational scenarios in the rail transit field). Upon receiving the task scenario requirements, a deep learning-based natural language processing model is used to semantically parse the natural language text, extracting scenario-related semantic features. Simultaneously, the numerical parameters of the parameterized input and the attribute data of the scenario template are structured using a rule parser. These multi-source, heterogeneous feature information are then uniformly mapped into a high-dimensional scenario feature vector space.

[0046] The construction of this scenario feature vector covers four key dimensions: environmental constraints, including space size limitations, passageway requirements, operating temperature range, vibration level, and protection level requirements; task function characteristics, including detection / operation type, motion mode (wheeled movement, legged walking, track gliding, etc.), positioning accuracy requirements, and operation method requirements; performance requirements, including load capacity, endurance, maximum operating speed, and repeatability; and physical constraints, including maximum external dimensions, weight limitations, and interface compatibility requirements. Taking the tunnel inspection scenario as an example, the scenario feature vector can be characterized as: [Workspace height range 0~3m, positioning accuracy ±5mm, protection level IP65, passage width ≥0.8m, vibration level 3G, endurance ≥4h]. This feature vector accurately reflects the special requirements of the rail transit tunnel environment on the robot.

[0047] The maintained physical modular hardware library is organized using a hierarchical index structure. The top layer is divided into computation and control modules, drive and execution modules, perception modules, and energy and structure modules according to functional categories. The middle layer records the physical attributes (such as size, weight, power consumption, and interface type) and technical parameters (such as torque range, perception accuracy, and computing power) of each module. The bottom layer stores 3D geometric model files, URDF unified robot description format files, interface definition files, and driver files. During the candidate component selection phase, the cosine similarity between the scene feature vector and the attribute vector of each module in the hardware library is calculated, and a multi-dimensional weighted scoring algorithm is used for comprehensive ranking. In the scoring algorithm, the weight of environmental constraint features is set to 0.35, the weight of task function features is set to 0.30, the weight of performance requirement features is set to 0.20, and the weight of physical constraint features is set to 0.15. By setting similarity thresholds and ranking rules, the system selects several modules with the highest scores to form a candidate component set.

[0048] Taking the undercarriage inspection scenario as an example, the user inputs "subway undercarriage surface defect detection robot". After parsing, key features are extracted: working space 0.6m×1.8m×2.0m (typical undercarriage space), protection level IP54, motion mode is moving plus cantilever operation, positioning accuracy ±2mm, and endurance ≥3h. Based on this, the system selects the following hardware from the hardware library: Haptic-WM02 hub motor drive module (suitable for channels within 0.8m), URG-04LX small lidar module (120° scanning angle suitable for undercarriage space), RAII-3L three-degree-of-freedom lightweight robotic arm module (1.2m extension radius to meet working space requirements), and VCAM-01 integrated vision module (1080p resolution to meet defect detection requirements).

[0049] After obtaining the candidate component set, the user selects the desired modules from the candidate set through a visual interactive interface. The user selects the target module on the interface by using checkboxes or clicking to generate the first scheduling instruction. This first scheduling instruction includes metadata such as the list of selected module identifiers, the number of modules, and the selection timestamp.

[0050] After selecting modules, users can use mouse drag-and-drop operations in the 3D virtual environment to spatially arrange and connect the selected modules. Each drag, rotation, and positioning operation by the user in the virtual space generates a second scheduling instruction. The second scheduling instruction includes the target module identifier, operation type (translation / rotation), spatial transformation parameters, and target connection interface information.

[0051] The rigid assembly technology relies on a three-in-one standard interface and a plug-and-play protocol. Each physical modular hardware unit is designed with a unified physical interface, including: a mechanical locking mechanism (a positioning-locking pair consisting of a positioning pin and a locking screw hole), high-current power contacts (gold finger contacts with a rated current of 10A), and a high-speed data communication bus (Mini-LVDS differential bus, bandwidth ≥500Mbps). When a user drags two modules within a preset distance threshold (recommended value 50mm) in the virtual environment, the system automatically detects the type compatibility of adjacent interfaces of the two modules. If the interface types match and the electrical parameters are compatible, the system automatically performs a virtual engagement operation and generates a connection relationship record.

[0052] At the coordinate system processing level, each module maintains its local coordinate system, and spatial transformations between modules are described by homogeneous transformation matrices. Once two modules are connected, the system determines connection constraints based on the geometric relative relationships of the interfaces and automatically establishes assembly constraints. These assembly constraints are added to the assembly model as rigid body motion constraints, and the system automatically updates the assembly reference coordinate system to unify the global coordinate system. After assembly, the system automatically generates an overall model of the 3D simulation robot. This overall model contains three core components: a geometric model (for visualization and collision detection), assembled from the 3D geometric models of all modules after spatial transformation; a physical model (for simulation calculations), containing overall mass distribution information, collision geometry definitions, and joint kinematic pair definitions; and a semantic model (for logic control), containing module function descriptions, interface connection topology, and control signal routing information.

[0053] Finally, kinematic and dynamic simulations were performed for verification and optimization, namely:

[0054] After the overall 3D simulation robot model is generated, corresponding kinematic and dynamic models are automatically established for kinematic and dynamic simulation verification. The kinematic model is established using the DH parameter method, traversing the assembly topology to extract the geometric parameters of all joints, including link length, link offset, joint rotation angle, and joint offset. For each joint, a corresponding DH parameter table is automatically generated, and the forward kinematic equations are established accordingly. The forward kinematic equations describe the mapping relationship between the end effector pose and joint variables in the form of a series of homogeneous transformation matrices. The inverse kinematics solution employs a numerical iterative algorithm based on the pseudo-inverse of the Jacobian matrix, supporting parallel solutions for multiple sets of solutions. For example:

[0055] The robot's joint chain is decomposed into a series of links, each described by four geometric parameters. For the i-th joint of the serially coupled robot arm, a local coordinate system {i} is established, with its DH parameters defined as follows:

[0056] Linkage torsion angle α i The physical meaning is around Z. i-1 Rotate the axis so that X i-1 Axis and X i The angle parallel to the axis, its dimension is rad; the length a of the connecting rod. i The physical meaning is Z. i-1 Axis and Z i The distance between axes, i.e., the length of the common perpendicular, is measured in meters; the link offset d i The physical meaning is along Z i-1 Axial direction, X i-1 Axis and X i The distance between axes, in meters; the joint angle θ i The physical meaning is around Z.i-1 Rotate the axis so that X i-1 Axis and X i The angle of axis alignment, measured in rad.

[0057] The standard DH parameter table is shown in Table 1:

[0058] Table 1: Standard DH Parameter Table

[0059]

[0060] For rotary joints, θ i For a moving unit, d is a variable; i For variables.

[0061] The coordinate transformation between adjacent links is described by a homogeneous transformation matrix. The homogeneous transformation matrix T from the (i-1)th coordinate system to the ith coordinate system is... i It is composed of four basic transformations:

[0062] ;

[0063] in, To circle around Z i-1 Axis rotation θ i Its physical meaning is the joint angle, that is, the rotation angle about the axis of the previous joint, Trans(Z) i-1 ,d i ) along Z i-1 Axis translation d i Its physical meaning is the link offset, the distance between the axes of two adjacent joints, Trans(X) i-1 ,a i-1 ) along axis X i-1 Translation a i-1 Its physical meaning is the link length, the length of the common normal of adjacent links, Rot(X) i-1 ,α i-1 ) for X i-1 Axis rotation α i-1 The physical meaning of is the torsion angle of the connecting rod, which is the angle between the axes of two adjacent joints.

[0064] Expanding the four transformations reveals the complete expression for the homogeneous transformation matrix of each joint:

[0065] ;

[0066] Where, θ i To circle around Z i-1 The joint angle of the axis, d i For along Z i-1 The joint offset of the axis, a i-1 For along X i-1The length of the connecting rod of the shaft, α i-1 For X i-1 The torsion angle of the shaft connecting rod.

[0067] Forward kinematics is a mapping from joint space to operand space. Based on the homogeneous transformation matrices of each joint, the pose matrix of the end effector relative to the base is obtained. We obtain this through matrix multiplication:

[0068] ;

[0069] After unfolding, the end-effector pose matrix is ​​in the form of:

[0070] ;

[0071] Wherein, the rotation matrix R=[n,o,e] of the end effector represents the attitude (3×3 orthogonal matrix), and the position vector P=[p] of the end effector in the base coordinate system. x ,p y ,p z ] T The terminal normal vector n = [n x ,n y ,n z ] T The end is close to the vector o=[o x ,o y ,o z ] T The end attitude vector e = [e x ,e y ,e z ] T T is the transpose.

[0072] Inverse kinematics is solved by deducing the joint variables from the known end-effector pose. Since analytical methods are difficult to handle redundant or singular configurations, this embodiment uses a numerical iterative algorithm based on the pseudo-inverse of the Jacobian matrix.

[0073] The dynamic model was established using the Newton-Euler recursive algorithm. This algorithm first calculates the velocity and acceleration of each rigid body recursively from the base towards the end effector (forward recursion), and then calculates the forces and moments of each joint recursively from the end effector towards the base (backward recursion). When establishing the dynamic model, factors such as gravity load, joint friction, end effector load, and inertial coupling are comprehensively considered. The parameters of the dynamic model are automatically extracted from the assembly physical model, including the mass, center of mass position, and inertial tensor of each rigid body.

[0074] The simulation verification process comprises three levels. First, in terms of motion range verification, forward and inverse kinematics calculations are used to verify whether the end effector's workspace meets task requirements, and to check whether the motion range of each joint is within physical limits. Second, in terms of interference checks, collision detection is performed during continuous motion in the simulation environment, including self-interference checks (collisions between robot components) and environmental interference checks (collisions between the robot and its working environment). For rail transit vehicle undercarriage inspection scenarios, the robot's maneuverability when navigating confined spaces such as curves and switches is verified. Third, in terms of dynamics verification, the driving torque of each joint is checked to ensure it is within the motor's rated torque range, the end effector load is within the structural bearing capacity range, and the overturning stability caused by the center of gravity distribution meets safety requirements.

[0075] Based on the simulation verification results, the 3D simulation robot is optimized and adjusted. For cases where joint torques exceed limits, the causes are analyzed and optimization suggestions are proposed, such as replacing the drive module with a higher power one, increasing the reduction ratio, or adjusting the transmission path. For cases where interference occurs, the interference location is identified, and adjustments to joint angle constraints or replacement with a more compact module are suggested. For cases of insufficient stability, it is recommended to add a counterweight module, adjust the center of gravity distribution, or add a support structure. After the user replaces modules, adjusts the configuration, or modifies parameters according to the optimization suggestions, the system re-executes the simulation verification, forming an iterative optimization closed loop.

[0076] This embodiment reduces the cost of physical prototyping and debugging through iterative optimization, lowers the development threshold, shortens the R&D cycle, takes into account hardware reusability and configuration flexibility, and ensures the reliability and adaptability of the robot in complex and restricted scenarios of rail transit.

[0077] Optionally, in one specific embodiment, the node library is established based on the following steps:

[0078] Based on the user-input general operation process, all standard functional nodes in the general operation process are obtained; the general operation process includes all operation processes during the normal operation of the rail transit inspection robot; and based on the node configuration file input by the user, the interface definition and configurable parameter set corresponding to each standard functional node are obtained; based on each standard functional node, and the interface definition and configurable parameter set corresponding to each standard functional node, a node description file corresponding to each standard functional node is established; based on the node description file corresponding to each standard functional node, a node library is constructed; wherein, each standard functional node in the node library has a corresponding index.

[0079] Specifically, this embodiment establishes a complete node library construction method for the application scenario of rail transit inspection robots. The node library is a basic component of the graphical behavior logic orchestration system, providing developers with reusable and configurable functional units. This technical solution can transform complex robot operation processes into standardized node combinations, enabling developers to complete complex behavior definitions without writing low-level code.

[0080] The general operation process covers the entire lifecycle of the robot, from startup and initialization, inspection operations, data acquisition, anomaly detection, alarm reporting to return to home and standby. Organized hierarchically, it is divided into three levels: primary main process, secondary sub-processes, and atomic operations. The primary main process includes: autonomous inspection process, fixed-point detection process, emergency response process, return to home and charging process, and system self-check process. Taking the autonomous inspection process as an example, the secondary sub-processes can be broken down into: environmental perception sub-process, path planning sub-process, task execution sub-process, and data upload sub-process. Atomic operations are the smallest units of process decomposition, such as reading LiDAR data and sending robotic arm control commands.

[0081] The extraction of standard functional nodes adopts a top-down, layer-by-layer decomposition strategy: first, core operation stages are identified from the primary main process; then, each stage is broken down into multiple secondary sub-processes; finally, the operation steps in the sub-processes are further decomposed to extract indivisible atomic operations as standard functional nodes. For example:

[0082] Perception nodes (LiDAR data acquisition nodes, visual camera acquisition nodes, IMU data reading nodes) are responsible for acquiring environmental information and robot status data from various sensors. Decision-making nodes (SLAM mapping nodes, global path planning nodes, target detection nodes, conditional branching nodes) are responsible for data processing, algorithm calculation, and logical decision-making. Control nodes (motion control nodes, joint position control nodes, gripper control nodes, relay control nodes) are responsible for sending control commands to actuators. Communication nodes (ROS2 topic publishing nodes, ROS2 service response nodes, data upload nodes) are responsible for exchanging data with other systems or modules. Tool nodes (data filtering nodes, coordinate transformation nodes, time synchronization nodes, log recording nodes) are responsible for data preprocessing and auxiliary functions.

[0083] Taking the autonomous inspection process under the vehicle as an example: The first-level process of autonomous inspection under the vehicle includes: the robot arrives at the inspection point → starts the under-vehicle scanning → performs segmented inspection → identifies anomalies → records data → returns to the standby point.

[0084] The process of arriving at the inspection point extracts the following nodes: scheduling instruction receiving node, path planning node, navigation movement node, and arrival judgment node;

[0085] The process of starting the undercarriage scanning subprocess extracts the following nodes: LiDAR data acquisition node, visual camera acquisition node, SLAM mapping node, and map update node.

[0086] The segmented inspection sub-process extracts the following nodes: LiDAR data acquisition node, obstacle detection node, local path planning node, and motion control node;

[0087] Anomaly identification sub-process extraction nodes: visual camera acquisition node, target detection node, anomaly judgment node;

[0088] Record data sub-process extraction nodes: data packaging node, image annotation node, location association node, and data storage node;

[0089] Through the above decomposition, more than 20 standard functional nodes were extracted from the autonomous inspection process under the vehicle, covering various functions such as perception, decision-making, control, and communication.

[0090] Node configuration files are in JSON or YAML format and are imported by the user through the configuration panel of a graphical IDE. The configuration file includes: basic node information, interface definition, parameter configuration, and dependency declaration.

[0091] The input interface includes: interface name, data type (e.g., sensor_msgs / LaserScan), topic name, message format description, and whether it is required.

[0092] The output interface includes: interface name, data type, output topic name, and message format description.

[0093] The service interface includes: service name, service type, and request / response message format.

[0094] The specific contents of the configurable parameter set include: algorithm parameters, such as filter window size, detection threshold, feature matching parameters, SLAM parameters, etc.; hardware parameters, such as sensor sampling frequency, control cycle, motor speed gain, etc.; and operating parameters, such as timeout time, number of retries, log level, debug switch, etc.

[0095] The node description file uses JSON format and has a mapping relationship with ROS2 nodes. For example, the `package_name` field in `os2_info` specifies the ROS 2 package name; `executable_name` specifies the executable file name; and `plugin_name` specifies the plugin library name. When a user drags and drops a node in the graphical IDE, the system automatically generates a launch file or composition command based on this mapping relationship to deploy the node to the ROS 2 runtime environment.

[0096] The node library adopts a multi-dimensional hierarchical organizational structure: The first layer is divided into five major categories according to function: perception node library, decision node library, control node library, communication node library, and tool node library; The second layer is further subdivided according to application scenarios under each category, such as the perception node library having LiDAR node set, vision node set, inertial measurement node set, etc.; The third layer is organized according to dependency hierarchy, reflecting the calling relationship between nodes.

[0097] The node library can be searched and accessed in ways including but not limited to: browsing the category tree, expanding the directory tree layer by layer according to functional categories; entering keywords such as name, type, and tags in the search box to search, supporting fuzzy matching and auto-completion; and dragging and dropping, directly dragging node icons from the node library panel into the workspace.

[0098] This embodiment establishes a node library, enabling developers to quickly construct various operational processes for rail transit inspection robots in a graphical IDE environment by dragging and dropping pre-defined nodes. These processes include tasks such as "laser SLAM mapping → global path planning → visual line following → target recognition → robotic arm grasping." Developers do not need to concern themselves with the underlying algorithm implementation and hardware driver details; they only need to focus on the arrangement of business logic, significantly improving development efficiency and lowering the development threshold. The completed flowcharts can be deployed to a virtual robot for verification in the Gazebo high-fidelity simulation environment with one click, or automatically converted into a ROS 2 executable code package for deployment to a real robot, achieving seamless iteration between simulation and physical implementation.

[0099] Optionally, in a specific embodiment, based on the requirements of the 3D simulation robot and the task scenario, and the physical properties corresponding to each 3D hardware model in the 3D simulation robot, multiple standard functional nodes are called from a pre-established node library to construct the task logic flowchart corresponding to the 3D simulation robot, including:

[0100] Based on the requirements of the task scenario, the corresponding task execution sequence is obtained, and based on the task execution sequence, multiple standard functional nodes are retrieved and called from the node library;

[0101] Based on the 3D simulation robot, all standard functional nodes are logically connected and parameters are configured to construct a task logic flowchart describing the entire cycle of robot operation. The task logic flowchart is used to define the closed-loop control logic of the 3D simulation robot from environmental perception to actuator action.

[0102] Specifically, in this embodiment, the task scenario requirements need to be transformed into a task execution sequence. The transformation methods typically include three types: based on scenario template mapping, the system pre-sets typical task templates (such as the "under-vehicle inspection" template, which includes steps such as entering the workstation, scanning and positioning, image acquisition, anomaly detection, report generation, and exiting the workstation), and automatically instantiates the template into a task execution sequence after the user selects it; based on task decomposition rules, for custom tasks, the system automatically decomposes them into atomic operation steps through semantic understanding and domain knowledge graphs; based on user interaction orchestration, the user manually constructs the execution sequence by dragging and dropping operation step cards.

[0103] The node library is organized using a hierarchical indexing mechanism (layered by function category, device model, and data type). The retrieval process is as follows: First, keywords are extracted and matched based on the semantics of the task steps, such as matching "image acquisition" with the "visual camera acquisition" node; then, candidate nodes are filtered based on the physical properties of the 3D simulation robot, and the best node is matched based on sensor model, joint type, and communication protocol; finally, the selected node is instantiated, inheriting the standard input / output interface definition.

[0104] The execution sequence and node mapping of the undercarriage inspection task are as follows:

[0105] Work steps: Move to the undercarriage workstation → LiDAR positioning → Undercarriage image acquisition → Image processing → Anomaly detection → Result judgment → Anomaly localization → Report generation; Corresponding standard functional nodes: Path planning node → LiDAR data acquisition node → Vision camera acquisition node → Data filtering node → Target detection node → Conditional branch node → Coordinate transformation node → Log recording node. Physical attribute selection criteria: Chassis kinematics model → RPLIDAR A3 → RealSense D435 → Standard processing algorithm → YOLOv8 algorithm → Logical judgment rules → Camera-radar calibration parameters → JSON report format.

[0106] Data flow connection: A data transmission path is established through the connection between the output port and the input port. The system automatically verifies port type compatibility; for example, a point cloud output port can only be connected to an input port that receives point clouds. Control flow connection: Conditional branches are implemented by connecting the trigger enable ports of different branch nodes through Boolean output ports; loop structures are implemented by connecting the first and last nodes of the loop body; parallel execution is achieved through parallel branches and parallel merging nodes to distribute and synchronize control flow.

[0107] Parameter configuration employs a strategy of "automatic configuration as the primary method, supplemented by manual adjustment." Automatic configuration includes: automatically filling in topic names (e.g., / camera / depth / image_raw) based on robot hardware configuration, setting control gain and limit thresholds based on joint parameters, and configuring path planning parameters based on the workspace. Manual adjustment allows users to modify parameters through a property configuration panel, supporting parameter validation and ROS 2 resource naming preview.

[0108] The task logic flowchart defines the closed-loop control logic from environmental perception to actuator action, including: Perception closed loop: sensor acquisition → filtering and noise reduction → feature extraction → decision judgment → actuator action → sensor feedback → continuous loop. This closed loop ensures the robot continuously responds to environmental changes. Safety closed loop: environmental monitoring → risk assessment → emergency stop → state recovery. This closed loop is embedded in the key nodes of the main process and has the highest priority to ensure operational safety. Specifically, a complete example of the undercarriage inspection task logic flowchart is: LiDAR data acquisition → point cloud filtering → SLAM localization → path planning → motion control → depth camera acquisition → image preprocessing → anomaly detection → conditional judgment → coordinate transformation → log recording → emergency stop.

[0109] Through the above solution, this embodiment realizes the automated construction from task requirements to task logic flowchart, and can complete the definition of complex robot operation behavior without writing low-level code, significantly reducing the application development threshold.

[0110] Optionally, in one specific embodiment, based on the task logic flowchart, the 3D simulation robot is subjected to operational simulation and logic verification to obtain a task execution strategy, including:

[0111] The task logic flowchart is loaded into a pre-set simulation engine to simulate the operation of the 3D simulation robot and obtain the simulation results. The simulation results include the logical verification results obtained by performing real-time logical verification on the operation status of each monitoring node of the 3D simulation robot during the simulation. Based on the simulation results, a task execution strategy is constructed to guide the static configuration parameters of the 3D simulation robot task.

[0112] Furthermore, based on the task execution strategy, the task logic flowchart is compiled and packaged to obtain the corresponding executable code. This includes: performing structural analysis on the task logic flowchart to extract all standard functional nodes and the connections between them; constructing a data flow dependency graph based on these nodes; building an intermediate representation file describing the operational logic of the 3D simulation robot based on the data flow dependency graph and the task execution strategy; traversing all standard functional nodes in the task logic flowchart based on the intermediate representation file to retrieve the code snippet corresponding to each node from a pre-established code template library; and statically configuring the task based on the task execution strategy. The system injects code snippets corresponding to each standard functional node in the task logic flowchart to configure placeholders for each code snippet. Based on all configured code snippets, it generates instantiated functional code tailored to the task scenario requirements. Based on the task logic flowchart, it logically assembles the instantiated functional code to generate the corresponding main program file. Based on the data flow dependency graph, it generates a project configuration file corresponding to the main program file. The project configuration file represents the call paths to external resources required to execute the main program file. Based on the project configuration file and a pre-configured compiler, it compiles the main program file and the external resources required to execute it to obtain an executable file. The executable file is then packaged according to a pre-configured directory structure to obtain a deployable image, which is the executable code.

[0113] Specifically, this embodiment details a complete technical solution for obtaining a task execution strategy through operational simulation and logic verification using a 3D simulation robot, and for compiling and packaging the task logic flowchart based on this strategy to obtain executable code. This solution achieves seamless integration from graphical task orchestration to physical robot deployment, significantly improving the efficiency of robot application development and deployment reliability.

[0114] In this embodiment, the simulation engine uses a high-fidelity simulation engine based on Gazebo and ROS 2 as the core simulation environment. When the simulation engine starts, it first loads the Unified Robot Description Format (URDF) model file of the 3D simulation robot. This model file fully describes the robot's kinematic parameters, geometric appearance, inertia matrix, collision attributes, and other physical characteristics. Simultaneously, it loads configuration parameters specific to the task scenario from the robot's physical parameter database, including but not limited to: joint limit angles, maximum angular velocity and angular acceleration, end effector load capacity, and sensor sampling frequency. Furthermore, the simulation engine loads the world file corresponding to the task scenario. This file defines environmental elements such as terrain, obstacle distribution, lighting conditions, and communication base station locations within the simulation environment. For applications in the rail transit field, the world file also includes specialized environmental information such as track parameters, platform locations, and signal status.

[0115] The simulation engine has a built-in flowchart parsing function, which is responsible for converting the task logic flowchart into a sequence of executable instructions for simulation. It first traverses all nodes in the flowchart and calls the corresponding instruction generator based on the node type (e.g., sensor node, control node, execution node). The instruction generator maps the node's input / output ports to the simulation engine's internal subscriber and publisher configurations, and encapsulates the node's internal logic into a state machine or callback function.

[0116] For sequentially executed node sequences, it generates sequential execution instructions; for parallel branch structures, it generates parallel scheduling instructions based on data flow dependencies; for conditional decision nodes, it generates conditional branch instructions and dynamically selects the execution path based on runtime data during simulation. After the conversion is complete, the simulation engine generates a unified Simulation Task Description File (STDF), which records the complete instruction execution sequence and resource dependencies.

[0117] The simulation engine drives the virtual robot to execute the converted sequence of task instructions. During execution, the simulation engine advances the simulation time at a set simulation step size (default 50ms), synchronously updating the virtual robot's pose, sensor data, internal variables, etc. The simulation engine's built-in physics engine (based on ODE or Bullet) calculates the virtual robot's dynamic response in real time, ensuring that the simulation results conform to physical laws. Taking a typical rail transit inspection task as an example, the simulation engine first drives the virtual robot to start from the charging pile location, controlling the mobile chassis to autonomously navigate along a preset track to the first inspection point; upon reaching the inspection point, the simulation engine triggers the vision sensor nodes to collect equipment image data and drives the image processing nodes to perform defect identification; after identification, the simulation engine controls the robotic arm nodes to perform fine inspection or marking actions based on the identification results; after all inspection point tasks are completed, the simulation engine drives the virtual robot to return to the charging pile, completing the entire task flow. Monitoring nodes and status acquisition include: several monitoring nodes are preset in the task logic flowchart to collect the virtual robot's operating status data during task execution. The monitoring nodes are divided into three categories: performance monitoring nodes, which collect system resource indicators such as CPU utilization, memory usage, and network bandwidth; sensor monitoring nodes, which collect sensor outputs such as LiDAR point cloud data, camera image data, and IMU inertial measurement data; and control monitoring nodes, which collect control feedback data such as robot pose, speed, joint angles, and actuator status. This embodiment employs a time-series database-based state acquisition mechanism. The monitoring nodes write the collected data to the time-series database according to a preset sampling frequency (default 10Hz) and export a complete runtime log file after the task is completed. This log file records the complete runtime status of the virtual robot at each simulation moment, supporting subsequent playback analysis and problem diagnosis.

[0118] The simulation engine's built-in logic verification module performs comprehensive logic verification on the simulation results, mainly including timing verification, data flow verification, state verification, and deadlock detection. Taking the laser SLAM mapping task as an example, the timing verification detects that the "path planning node" starts before the "map building node," violating the "map building before planning" timing constraint, resulting in an error and locating the path planning node with node ID ND_042. The data flow verification detects that the data type of the "map data output port" is nav_msgs / OccupancyGrid, while the expected data type of the "path planning input port" is nav_msgs / OccupancyGrid; the types are consistent, and the verification passes. The state verification detects an abnormal jump in the laser radar scan data at simulation time 1567, exceeding the normal value range [-30, 30] dBm, triggering a state anomaly alarm.

[0119] Based on the logical verification results from the simulation, this embodiment constructs a task execution strategy encompassing four dimensions: task scheduling strategy, resource allocation strategy, parameter optimization strategy, and fault tolerance strategy. The parameter optimization strategy derives parameter optimization suggestions based on detailed data from the logical verification results. Taking a visual line-following node as an example, if the simulation results show a line-following success rate of only 78%, and analysis reveals that the high false detection rate is due to improper line-following threshold configuration, the parameter optimization strategy generates the following suggestions: adjust the "line-following confidence threshold" from 0.6 to 0.75, adjust the "line-following area width" from 80 pixels to 100 pixels, and adjust the "maximum bending angle" from 15 degrees to 12 degrees. The optimization suggestions are output in the form of structured parameter adjustment instructions for subsequent steps.

[0120] Then, the task logic flowchart is subjected to structured parsing, that is, a depth-first traversal of the task logic flowchart is performed to extract topological structure information. The parsing process first traverses all nodes, generating a node set N={n1,n2,...,nm}, where each node contains attributes such as a unique identifier, node type, input port list, output port list, and configuration parameters. Subsequently, all connections are traversed, generating a connection set E={(src,dst)|src,dst∈N}, where each connection connects the output port of the source node src to the input port of the target node dst.

[0121] Subsequently, a data flow dependency graph is constructed, which is a directed acyclic graph (DAG) with the set of nodes as the set of vertices and the set of connections as the set of directed edges. Each directed edge is labeled with the data type it transmits, forming a typed data flow dependency graph. For conditional branch structures in the task logic flowchart, the parsing module models them as directed edges with conditional labels; for parallel structures, the parsing module uses dashed boxes to identify parallel execution regions and synchronizes the execution results of parallel branches based on barrier nodes. An adjacency list is used as the storage format for the data flow dependency graph, and the topological sorting result is used as the node execution sequence.

[0122] Next, an intermediate representation file is constructed using JSON format, serving as a bridge between the task logic flowchart and the underlying code generation. The intermediate representation file contains the following core fields: the `nodes` array records metadata about all standard functional nodes, including node ID, node type, input / output port definitions, and the functional module to which they belong; the `connections` array records the connection relationships between nodes, with each connection recording the source node ID, source port name, target node ID, target port name, and data type; the `scheduling` field records the task scheduling strategy, including node execution order, priority, and synchronization barriers; and the `parameters` field records the task's static configuration parameters, including path planning parameters, detection thresholds, control gain, and timeout.

[0123] Furthermore, the code template library retrieval process involves querying the code template library index table based on the node ID in the intermediate representation file to obtain the path to the corresponding node type's code template file. The retrieval process employs an exact matching strategy to ensure a one-to-one correspondence between templates and node types, thereby obtaining code snippets. For custom nodes, the code template library supports user-uploaded custom templates and their registration in the index table. The code template library is stored on the local file system and uses a dual index of node type and template version number. Each standard functional node corresponds to one code template file, which contains the node's core functional code, ROS 2 interface definitions, parameter configuration sections, etc. Code templates are categorized and managed according to programming language (e.g., Python, C++) and ROS 2 distribution (e.g., Foxy, Galactic) to ensure that the generated code matches the target robot's operating environment.

[0124] After obtaining the code snippet, parameter injection is performed, which involves reading the `parameters` and `nodes` fields from the intermediate representation file and iterating through the configuration parameters of all nodes. For each parameter to be injected, the parameter injection module locates its placeholder position in the corresponding code template and replaces the placeholder with the actual parameter value. The replacement process uses string template rendering technology to ensure that the parameter type and format match correctly. After injection is complete, the parameter injection module generates instantiated functional code files, with each node corresponding to an independent code file.

[0125] Subsequently, the main program file and project configuration are generated. The main program file, based on the topology sorting result and following the logical order of the task logic flowchart, assembles the instantiation function code of each node into a complete ROS 2 executable program. This embodiment generates two types of main program files: for single-node tasks, a separate Python executable script or C++ executable file is generated; for multi-node collaborative tasks, a launch file (.launch.py) is generated, defining node startup parameters and namespaces. The project configuration file is generated based on the data flow dependency graph and is used to describe the structure and dependencies of ROS 2 function packages. This embodiment generates a standard ROS 2 project configuration file, including: package.xml defining function package metadata and dependency declarations; CMakeLists.txt or setup.py defining compilation rules and installation paths; the config directory storing parameter configuration files for each node; and the launch directory storing launch files.

[0126] After generating the main program file and project configuration, the main program file and external dependent resources are compiled and linked using the ROS 2 compiler (colcon). The compilation process first parses package.xml to obtain the dependency list, automatically downloads and installs missing dependency packages; then, it executes the build command to package and install the Python code and compile and link the C++ code; finally, it executes the test command to run unit tests and integration tests to verify the build artifacts.

[0127] After compilation, the compilation module organizes the generated files according to a preset directory structure. This embodiment uses Docker containerization technology to encapsulate all program files, dependency libraries, configuration files, startup scripts, etc., into a complete deployable image. The directory structure of the deployable image conforms to the ROS 2 file system standard and includes a Dockerfile to describe the image building process.

[0128] The generated deployable image supports two deployment methods: one-click deployment, where the platform management software pushes the image to the target robot device via SSH or Docker API and automatically starts running; and OTA over-the-air update, which uses differential update technology to transmit only the changed parts to the target device, reducing update bandwidth consumption and is suitable for batch deployment scenarios of multiple robot clusters.

[0129] This embodiment fully describes the chain from simulation verification to code compilation and deployment, realizing a seamless connection between graphical programming and physical robot deployment, and significantly improving the development and deployment efficiency of robot applications.

[0130] In addition, this embodiment provides a software and hardware development system for an inspection robot, which is applied in the field of rail transit. The system architecture is as follows: Figure 2 As shown, it includes:

[0131] The simulation model building module is used to call multiple 3D hardware models from a pre-established physical modular hardware library based on the user-input task scenario requirements, in order to perform 3D modeling of the task scenario requirements and obtain the 3D simulation robot corresponding to the task requirements; each 3D hardware model has corresponding physical properties.

[0132] The task logic construction module is used to construct the task logic flowchart for the 3D simulation robot by calling multiple standard functional nodes from a pre-established node library based on the requirements of the 3D simulation robot and the task scenario, as well as the physical attributes of each 3D hardware model in the 3D simulation robot. Based on the task logic flowchart, the module performs runtime simulation and logic verification on the 3D simulation robot to obtain the task execution strategy. The task logic flowchart is a data flow diagram that connects all standard functional nodes in a logical order through graphical connections.

[0133] The task code distribution module is used to compile and package the task logic flowchart based on the task execution strategy to obtain the corresponding executable code, and then distribute the executable code to the physical robot to drive the physical robot to perform the tasks required by the task scenario. The physical robot is a physical robot that is pre-built based on the task scenario requirements and has the same architecture as the 3D simulation robot.

[0134] Furthermore, the system also includes: a remote cloud platform, and cloud-based collaborative processes such as... Figure 5 As shown;

[0135] The remote cloud platform is used in conjunction with the task code distribution module to distribute executable code to the physical robot, so as to drive the physical robot to perform the tasks required by the task scenario.

[0136] Furthermore, when the physical robot performs tasks corresponding to the requirements of the task scenario based on executable code, synchronous simulation operations are performed based on the 3D simulation robot and the task logic flowchart;

[0137] The system acquires real-time physical operation data during the operation of the physical robot and real-time simulation operation data during the synchronous simulation operation of the 3D simulation robot; and based on the real-time physical operation data and real-time simulation operation data, it determines whether to send an emergency control command to the physical robot.

[0138] Furthermore, in this embodiment, developers can utilize stronger computing power on a remote cloud platform to train algorithms and conduct large-scale simulation tests, and synchronize the results to the edge.

[0139] Furthermore,

[0140] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make modifications, alterations, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A software and hardware development method for an inspection robot, characterized in that, The method is applied in the field of rail transit, including: Based on the task scenario requirements input by the user, multiple 3D hardware models are called from a pre-established physical modular hardware library to perform 3D modeling of the task scenario requirements and obtain a 3D simulation robot corresponding to the task requirements; wherein, each 3D hardware model has corresponding physical properties. Based on the requirements of the 3D simulation robot and the task scenario, as well as the physical attributes of each 3D hardware model in the 3D simulation robot, multiple standard functional nodes are called from a pre-established node library to construct the task logic flowchart corresponding to the 3D simulation robot. Based on the task logic flowchart, the 3D simulation robot is subjected to operation simulation and logic verification to obtain the task execution strategy. The task logic flowchart is a data flow diagram that connects all standard functional nodes in a logical order through graphical connections. Based on the task execution strategy, the task logic flowchart is compiled and packaged to obtain the corresponding executable code, and the executable code is sent to the physical robot to drive the physical robot to perform the tasks required by the task scenario; the physical robot is a physical robot pre-built based on the task scenario requirements and has the same architecture as the 3D simulation robot.

2. The software and hardware development method for the inspection robot according to claim 1, characterized in that, The physical modular hardware library is built based on the following steps: Based on the standard functional requirements input by users, the rail transit inspection robot is functionally decoupled to divide it into multiple standard components, each of which has corresponding component attributes; the standard functional requirements are the functional requirements necessary for the normal operation of the rail transit inspection robot. Each standard component is subjected to 3D geometric modeling to generate a corresponding 3D hardware model. The physical interface and interface protocol of each 3D hardware model are configured, and the physical interface and interface protocol of all 3D hardware models are consistent. Each 3D hardware model has corresponding hardware attributes, and the physical attributes are obtained based on the corresponding component attributes. Based on each 3D hardware model and its corresponding physical attributes, a hardware description file is generated for each 3D hardware model; the physical attributes include hardware attributes, physical interfaces, and interface protocols. A physical modular hardware library is constructed based on the hardware description file corresponding to each 3D hardware model; each hardware description file in the physical modular hardware library has a corresponding index.

3. The software and hardware development method for the inspection robot according to claim 1, characterized in that, Based on the user-inputted task scenario requirements, multiple 3D hardware models are called from a pre-established physical modular hardware library to perform 3D modeling of the task scenario requirements, thereby obtaining a 3D simulation robot corresponding to the task requirements, including: The task scenario requirements input by the user are processed to extract features and obtain the corresponding scenario feature vector. Based on the scenario feature vector, all 3D hardware models in the physical modular hardware library are screened to obtain a set of candidate components. Based on the first scheduling instruction input by the user, multiple three-dimensional hardware models are selected from the candidate component set, and based on the second scheduling instruction input by the user, the selected three-dimensional hardware models are rigidly assembled to obtain the three-dimensional simulation robot corresponding to the task requirements.

4. The software and hardware development method for the inspection robot according to claim 3, characterized in that, Based on the user-inputted task scenario requirements, multiple 3D hardware models are called from a pre-established physical modular hardware library to perform 3D modeling of the task scenario requirements, thereby obtaining a 3D simulation robot corresponding to the task requirements. The system also includes: After obtaining the 3D simulation robot corresponding to the task requirements, a dynamic model and a kinematic model of the 3D simulation robot are established based on the physical properties of each 3D hardware model in the 3D simulation robot. Kinematic simulation verification and dynamic simulation verification are performed on the 3D simulation robot to obtain the corresponding simulation verification results. The 3D simulation robot is then optimized and adjusted based on the verification results.

5. The software and hardware development method for the inspection robot according to claim 1, characterized in that, The node library is established based on the following steps: Based on the user-input general operation process, all standard functional nodes in the general operation process are obtained; the general operation process includes all operation processes when the rail transit inspection robot is running normally; Based on the node configuration file input by the user, the interface definition and configurable parameter set corresponding to each standard functional node are obtained; Based on each standard functional node, and the corresponding interface definition and configurable parameter set of each standard functional node, a node description file corresponding to each standard functional node is established. A node library is constructed based on the node description file corresponding to each standard functional node; each standard functional node in the node library has a corresponding index.

6. The software and hardware development method for the inspection robot according to claim 1, characterized in that, Based on the requirements of the 3D simulation robot and the task scenario, as well as the physical properties corresponding to each 3D hardware model in the 3D simulation robot, multiple standard functional nodes are called from a pre-established node library to construct the task logic flowchart corresponding to the 3D simulation robot, including: Based on the task scenario requirements, a corresponding task execution sequence is obtained, and based on the task execution sequence, multiple standard functional nodes are retrieved from the node library and invoked. Based on the aforementioned 3D simulation robot, all standard functional nodes are logically connected and their parameters are configured to construct a task logic flowchart describing the entire cycle of robot operation. The task logic flowchart is used to define the closed-loop control logic of the 3D simulation robot from environmental perception to actuator action.

7. The software and hardware development method for the inspection robot according to claim 1, characterized in that, Based on the task logic flowchart, the 3D simulation robot is subjected to operational simulation and logic verification to obtain the task execution strategy, including: The task logic flowchart is loaded into a pre-set simulation engine to perform a simulation of the three-dimensional simulation robot and obtain simulation results. The simulation results include the logic verification results obtained by performing real-time logical verification on the running status of each monitoring node of the three-dimensional simulation robot during the simulation process. Based on the simulation results, a task execution strategy is constructed to guide the static configuration parameters of the 3D simulation robot task.

8. The software and hardware development method for the inspection robot according to claim 7, characterized in that, Based on the task execution strategy, the task logic flowchart is compiled and packaged to obtain the corresponding executable code, including: The task logic flowchart is structurally analyzed to extract all standard functional nodes in the task logic flowchart and the connection relationships between each standard functional node; and a data flow dependency graph is constructed based on all standard functional nodes in the task logic flowchart and the connection relationships between each standard functional node. Based on the data flow dependency graph and task execution strategy, an intermediate representation file is constructed to describe the operation logic of a 3D simulation robot. Based on the intermediate representation file, all standard functional nodes in the task logic flowchart are traversed to retrieve the code snippet corresponding to each standard functional node in the task logic flowchart from the pre-established code template library. Based on the task execution strategy, the static configuration parameters of the task are injected into the code snippet corresponding to each standard functional node in the task logic flowchart to configure the placeholders of each code snippet, and based on all the configured code snippets, instantiated functional code for the task scenario requirements is generated. Based on the task logic flowchart, the instantiated function code is logically assembled to generate the corresponding main program file, and based on the data flow dependency graph, the corresponding project configuration file is generated; wherein, the project configuration file is used to represent the call path of external resources required to execute the main program file; Based on the project configuration file and the pre-configured compiler, the main program file and the external resources required to execute the main program file are compiled to obtain an executable file. The executable file is then packaged according to a pre-configured directory structure to obtain a deployable image, which is the executable code.

9. A software and hardware development system for an inspection robot, characterized in that, The system is applied in the field of rail transit, and the system includes: The simulation model building module is used to call multiple 3D hardware models from a pre-established physical modular hardware library based on the user-input task scenario requirements, so as to perform 3D modeling of the task scenario requirements and obtain the 3D simulation robot corresponding to the task requirements; wherein, each 3D hardware model has corresponding physical properties. The task logic construction module is used to construct a task logic flowchart for the 3D simulation robot by calling multiple standard functional nodes from a pre-established node library based on the requirements of the 3D simulation robot and the task scenario, as well as the physical attributes corresponding to each 3D hardware model in the 3D simulation robot. Based on the task logic flowchart, the module performs runtime simulation and logic verification on the 3D simulation robot to obtain the task execution strategy. The task logic flowchart is a data flow diagram that connects all standard functional nodes in a logical order using graphical connections. The task code distribution module is used to compile and package the task logic flowchart based on the task execution strategy to obtain the corresponding executable code, and distribute the executable code to the physical robot to drive the physical robot to perform the work corresponding to the task scenario requirements; wherein, the physical robot is a physical robot pre-built based on the task scenario requirements and has the same architecture as the 3D simulation robot.

10. The software and hardware development system for the inspection robot according to claim 9, characterized in that, The system also includes: a remote cloud platform; The remote cloud platform is used to perform synchronous simulation operations based on the 3D simulation robot and the task logic flowchart when the physical robot performs the task corresponding to the task scenario requirements based on the executable code. The system acquires real-time physical operation data during the operation of the physical robot and real-time simulation operation data during the synchronous simulation operation of the 3D simulation robot; and based on the real-time physical operation data and real-time simulation operation data, it determines whether to send an emergency control command to the physical robot.

Images