Configuration generation method, reconfiguration planning method and robot for reconfigurable modular robot system

Abstract

The application discloses a configuration generation method, a reconfiguration planning method and a robot of a reconfigurable modular robot system, and belongs to the technical field of robots.The configuration generation method comprises the following steps: dividing robot modules into five categories according to functional roles and topological positions, and establishing four-layer interface contract descriptions containing interface level declaration parameters, mechanical coupling parameters, electrical transmission parameters and communication protocol parameters for each interface surface of each module; receiving task requirements and extracting a functional type requirement set; enumerating candidate configurations and sequentially performing interface level matching pre-checking, mechanical coupling compatibility checking, electrical compatibility checking and communication protocol compatibility checking on the interfaces of adjacent modules; performing functional integrity verification on the candidate configurations that pass the checking; and selecting a target configuration from the effective configurations according to an optimization target and outputting the target configuration.The application realizes automatic configuration generation and compatibility checking of a modular robot system that is decoupled from physical implementation.

Description

Technical Field

[0001] This invention relates to the field of robotics, specifically to a configuration generation method, a reconfiguration planning method, and a robot for a reconfigurable modular robot system. Background Technology

[0002] With the widespread application of robotics technology in industries such as industry, aerospace, and disaster relief, increasingly higher demands are being placed on the environmental and task adaptability of robots. Reconfigurable modular robots consist of a series of functionally distinct unit modules. Each module autonomously changes its configuration through connection and disconnection actions to adapt to different environments and task requirements, demonstrating significant advantages in operating in unknown environments.

[0003] However, the existing field of reconfigurable modular robots suffers from the following systemic defects: First, there is a lack of a unified module classification system. Existing solutions are all designed with closed systems for self-developed modules, making it impossible to manage modules from different sources under a unified framework. Second, the interface design is asymmetrical between active and passive modes, limiting the arbitrariness of reconfigurable topologies. Third, there is a lack of standardized description formats at the interface level. Existing patents protect specific physical interface structures, without defining interface contract specifications independent of specific physical implementations. Fourth, there is a lack of systematic hierarchical schemes for interfaces with different load-bearing requirements. High-load-bearing connections near the torso and lightweight connections at the end effector are not uniformly incorporated into the same specification framework. Fifth, the control system relies on manually inputting configuration information and lacks a mechanism for the system to automatically perceive the current physical connection topology.

[0004] The root cause of the above-mentioned defects is that the field of modular robots still lacks a design methodology framework that is decoupled from specific physical implementations, so that any module that conforms to the framework specifications can be automatically verified for compatibility and automatically generated with valid configurations. Summary of the Invention

[0005] The core technical problem to be solved by this invention is: how to define a modular robot system design framework that is independent of specific physical interface implementation, so as to achieve: (1) systematically classify robot modules with arbitrary functions; (2) automatically determine the connection compatibility of any two modules through two-level interface contracts; (3) automatically generate effective configurations according to task requirements; and (4) systematically plan the reconstruction path from one effective configuration to another.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: This invention provides a configuration generation method for a reconfigurable modular robot system, comprising the following steps: Step (a): Establish a module classification system and interface contract description.

[0007] Robot modules are divided into five categories based on their functional roles and topological positions. These five categories include: Class I – Core Structure: Represented by the torso and hip base, this is a multi-interface hub module that defines the overall robot topology. It has four or more interface surfaces, simultaneously supporting both high-load-bearing and standard-load interfaces, with extremely low reconfiguration frequency. A robot system can contain two or more Class I modules, serving as the root node and intermediate hub node of the topology tree, respectively.

[0008] Type II – Degrees of Freedom Joints: Represented by the lumbar, shoulder, and hip joints, these are independent joint modules that provide rotational or translational degrees of freedom between two modules. They have two interface surfaces, both ends of which use high-load-bearing interfaces, resulting in low reconfiguration frequency. The root of each limb chain is connected to the Type I core structure by a Type II joint.

[0009] Category III – Drive-Integrated Linkages: Represented by the boom, forearm, thigh, and calf, these are linkage modules integrating structure and drive, with built-in motors, reducers, and encoders. They have two interface surfaces. The first linkage section (boom, thigh) uses a high-load-bearing interface at the near end and a standard-grade interface at the far end, acting as a bridge module between the two interfaces; subsequent linkages (forearm, calf) use standard-grade interfaces at both ends, with a moderate reconfiguration frequency.

[0010] Class IV – End Effectors: Represented by wheels, feet, and hands, these are end-effectors of the kinematic chain, performing direct interaction with the environment. They have a single interface surface, use a standard-level interface, and have a high reconfiguration frequency.

[0011] Class V – Functional Accessories: Represented by control modules, sensing modules, and power supplies, these are non-kinematic functional modules that can be attached to the standard interface surface of any module. They have one interface surface, use a standard interface, and have a moderate reconfiguration frequency.

[0012] The above classification system reveals that the Class III first-section drive integrated link undertakes the interface level bridging function—the high-load-bearing interface at the near end bears the large load from the joint or trunk, while the standard interface at the far end is open to the end of the chain, so that the end module remains lightweight and standardized.

[0013] Simultaneously, a four-layer interface contract description is established for each interface surface of each module. The interface contract description includes: Layer 1—Interface Level Declaration Parameters: Includes a level identifier field `tier` and a direction / role field `role`. The `tier` value is either "H" for high-load capacity or "S" for standard capacity. The `role` value is either "proximal" (the interface face is located on the side of the module closer to the root node of the kinematic chain), "distal" (the interface face is located on the side of the module farther from the root node of the kinematic chain), or "neutral" (the interface face has no fixed upstream / downstream direction). The compatibility rule is: the proximal end must dock with the far end, or both must be neutral for interconnection. The `role` field only declares the topological direction of the interface face in the kinematic chain and does not describe the relationship between active and passive components in the mechanical structure. The same interface face can assume an upstream or downstream role as needed for assembly, thereby eliminating the limitation on the arbitrariness of topology reconstruction imposed by the asymmetry of active and passive interfaces in existing solutions.

[0014] Layer 2 — Mechanical Coupling Parameters: Includes coupling type identifier, rated load capacity, rated load torque, alignment tolerance level, and connection direction set.

[0015] Layer 3 — Electrical transmission parameters: including rated operating voltage range, rated current, power supply direction capability, hot-swap support mark, and electrical contact layout identifier.

[0016] Layer 4—Communication Protocol Parameters: Includes communication protocol identifier, communication bandwidth, communication role, and address allocation method.

[0017] Interface contracts are stored in a standardized JSON Schema format. Each module provides a contract description file for each of its interface surfaces, all stored uniformly in the module library and automatically parsed by the configuration generation system. This step abstracts the module interface specifications from the specific physical structure, completely decoupling the interface contract from the specific physical implementation. Any interface form that satisfies the contract can be incorporated into the framework, without limiting the space for hardware innovation. Simultaneously, the two-level interfaces precisely match the load distribution: high-load-bearing interfaces are concentrated in high-load locations near the torso, while standard-level interfaces cover lightweight end-effector scenarios, balancing system structural strength with low-cost standardization of end-effector modules. Through the bridging principle from high-load-bearing to standard levels in the Class III first-section connecting rod, a systematic principle is provided for the design of new limb configurations, reducing design freedom and lowering the error rate.

[0018] Step (b): Receive task requirements, parse and extract the set of functional type requirements, search the module library for candidate modules that can provide each functional type in the set of requirements, and according to the topological constraint rules of the module classification system described in step (a), include the core structure, degree-of-freedom joints and drive integrated linkages necessary to support the candidate modules, and jointly construct the candidate module pool.

[0019] Receive task requirements submitted by users, parse and extract the set of functional type requirements F={f1, f2, ..., f n Functional type requirements refer to an enumerated set of various robot functions needed to complete a specific task; their representation dimension is functional capability rather than module category. Each element in F is represented as a tuple f. i =(c i q i ), where c i q is the function type identifier. i The quantity requirement for this feature type indicates that q must be included in the generated configuration. i A module that can independently provide this type of functionality.

[0020] For example, after analyzing the task "Industrial Site Inspection and Material Handling", we get: F = {(All-terrain mobility, 4), (Grasping operation capability, 2), (Environmental perception capability, 1), (Central control capability, 2), (Autonomous power supply capability, 1)} Among them, the number 4 of all-terrain mobility corresponds to four independent leg chains, the number 2 of grasping operation capability corresponds to two independent arm chains, the number 2 of central control capability is used to meet the redundancy requirements of the control system, the environmental perception capability is provided by a perception module that combines lidar and camera, and the autonomous power supply capability is provided by a power module.

[0021] Subsequently, a candidate module pool M_pool is constructed, including: firstly, searching the module library for modules that can provide c i The modules of the aforementioned functional type, according to the quantity requirement q i First, the necessary core structures, degree-of-freedom joints, and drive integrated linkages required to support the aforementioned functional modules are included, forming a subset of structural support modules, according to the topological constraint rules of the five types of module systems described in step (a). The union of the two subsets is the candidate module pool M_pool.

[0022] This step allows non-specialists to obtain a complete solution simply by describing the task requirements, eliminating the reliance on the experience of professional engineers.

[0023] Step (c): Enumerate the candidate module connection topology, generate a candidate configuration set, and for any pair of adjacent module interfaces in each candidate configuration, perform interface level matching pre-verification, mechanical coupling compatibility verification, electrical compatibility verification, and communication protocol compatibility verification in sequence. If all four verifications pass, the interface is determined to be contract compatible.

[0024] Enumerating the candidate module connection topology involves, after the candidate module pool M_pool is determined, listing all possible module combinations and connection methods according to the robot's topology constraints (Class I core structures as root nodes and intermediate hub nodes, Class II joints connecting the roots of each limb chain, Class III links extending, Class IV modules located at the ends of kinematic chains, and Class V modules attached to any standard-level interface surface). Each legal combination forms a candidate configuration. In implementation, a graph search (depth-first or breadth-first) starting from the root node can be used, pruning under the topology constraints of the five module categories to control the size of the candidate configuration set.

[0025] For any pair of adjacent module interfaces in each candidate configuration, perform the following four verification steps in sequence: Step 1: Interface Level Matching Pre-validation. This step verifies whether the tier fields of the two interfaces are identical (H to H or S to S); and whether the role fields are complementary (proximal to discrete, or both are neutral). If either condition is not met, the interfaces are deemed incompatible, rejected outright, and the subsequent three steps are skipped. This step significantly reduces the overhead of invalid validation through low-cost pre-screening.

[0026] Step 2: Mechanical Coupling Compatibility Verification. Verify whether the coupling type identifier belongs to a defined mating type pair; verify whether the rated load capacity meets the task load requirements; verify whether the alignment tolerance level meets the deployment environment requirements; verify whether the connection direction set has a non-empty intersection. If any of these conditions are not met, mechanical incompatibility is determined.

[0027] Step 3: Electrical Compatibility Verification. Verify whether the voltage ranges overlap (the voltage ranges of the power supply side and the power receiving side intersect); verify whether the current capability of the power supply side meets the requirements of the power receiving side; verify whether the electrical contact layout identifiers match; if hot-swapping is required, verify that both sides support it. If any of these conditions are not met, electrical incompatibility is determined.

[0028] Step 4: Communication Protocol Compatibility Verification. Verify that the protocol identifiers are the same or belong to a defined interoperable protocol pair; verify that the communication role combination is valid; verify that the communication bandwidth meets the task requirements; verify that the address allocation method is compatible. If any of these conditions are not met, the communication is deemed incompatible.

[0029] If all four steps pass, the interface is deemed contract-compatible; if all adjacent module interface pairs in the candidate configuration are deemed contract-compatible, the candidate configuration is deemed to have passed verification. This step uses four automated verification steps, allowing the system to automatically determine whether any two module interfaces can be connected, eliminating the need for manual judgment.

[0030] Step (d): Perform functional integrity verification on the candidate configurations that pass the verification. For each functional requirement in the set of functional type requirements parsed in step (b), count the number of modules in the candidate configurations that can provide that functional type, and verify whether the number is not less than the number requirement of that functional requirement. If all functional requirements are met, the functional integrity verification is passed. The candidate configurations that pass the four-step verification and the functional integrity verification are defined as valid configurations.

[0031] Functional integrity verification refers to checking whether the set of functional types provided by all modules in the candidate configuration completely covers every item and its quantity requirement in the set of functional type requirements F obtained in step (b). Specifically, it iterates through each functional requirement f in F. i =(c i q i The module list of candidate configurations can provide functional type c. i The number of modules is checked to ensure that the number is not less than the required number q. i If all functional requirements in F are met, the verification passes; if any functional requirement has fewer modules than its required quantity q, the verification fails. i If the candidate configuration is invalid, then the candidate configuration is deemed invalid.

[0032] Step (e): Select the target configuration from the valid configurations according to the optimization objective, and output the module list and assembly sequence of the configuration.

[0033] The system selects a target configuration from the available configurations based on optimization objectives. Optimization objectives include at least one of the following: minimum total number of modules, minimum system energy consumption, maximum redundancy, and minimum number of refactoring steps. Users can specify a single objective or a weighted combination, and the system will select the optimal configuration from the available configuration set accordingly.

[0034] An assembly sequence is a list of ordered operational steps to assemble the various modules of a target configuration from their component state into a complete robot. Each step includes: operation type (installation or connection), operation object (specific module ID and corresponding interface number), interface level identifier (H or S), and operation parameters (such as locking torque). The sequence is ordered according to dependency constraints: high-load-bearing level connections are established before standard-level connections that depend on them; the supported module is in place before the modules that depend on it are installed. The assembly sequence can be executed directly by workers or automated assembly systems without manual judgment of the order.

[0035] This invention also provides a reconfiguration planning method for a reconfigurable modular robot system, comprising the following steps: Step 1: Obtain the current configuration topology graph G_current and the target configuration topology graph G_target.

[0036] The configuration topology diagram is a graph structure with each module in the robot system as a node and the interface connections between modules as directed edges, which fully describes the robot's configuration. Each node records the module ID and category, and each directed edge records the interface number and level (H or S) of the interface it connects to.

[0037] The `G_current` parameter is automatically obtained through topology awareness or entered by the user. Topology awareness refers to the automatic identification of adjacent module IDs and interface levels through interface-level near-field communication when a module experiences a physical connection or disconnection event, and the real-time construction of the current configuration topology map. The `G_target` parameter is output by the above configuration generation method or specified by the user.

[0038] Step 2: Calculate the graph difference between G_current and G_target to obtain the set of connections to be disconnected and modules to be removed (Ops_remove) and the set of modules to be added and connections to be established (Ops_add).

[0039] Graph difference calculation compares the graph structures of G_current and G_target, outputting two sets of differences: Ops_remove = {module nodes that exist in G_current but not in G_target} ∪ {connection edges that exist in G_current but are broken in G_target}, which are the elements that need to be removed from the current configuration.

[0040] Ops_add = {module nodes that exist in G_target but not in G_current} ∪ {connection edges that need to be created in G_target}, which are the elements that need to be added to the current configuration.

[0041] The union of the two sets represents all the atomic operations required to complete this reconstruction.

[0042] Step 3: Sort the operation set obtained by merging Ops_remove and Ops_add to generate an operation sequence that satisfies structural stability constraints, interface level constraints, and dependency constraints.

[0043] The structural stability constraint ensures that the topology remains connected after each operation (without creating dangling subgraphs). Operation sequences that violate this constraint are excluded by the sorting algorithm. This guarantees that the robot structure remains stable throughout the reconstruction process, avoiding safety risks caused by topological breaks.

[0044] The interface level constraint stipulates that high-load-bearing level connections are established and stabilized before the standard level connections that depend on them, and are disconnected after the standard level connections that depend on them during disassembly. Operation sequences that violate this constraint are excluded. This ensures that high-load-bearing connections are established and stabilized first during assembly and last during disassembly, providing reliable mechanical support for the lightweight connections that depend on them throughout the entire process.

[0045] The dependency constraint states that the dependent connection is established before the connections that depend on it. Operation sequences that violate this constraint are excluded. This ensures that the order of connection establishment conforms to the physical dependencies, avoiding assembly failures due to incorrect ordering.

[0046] The sorting algorithm can use topological sorting to output the final operation sequence that satisfies the above constraints.

[0047] Step 4: Output the refactoring operation sequence, each step including operation type, object module ID and interface number, and interface level identifier.

[0048] Each step in the refactoring operation sequence includes: operation type (disconnect, remove, insert, or connect), object module ID and interface face number, interface level identifier (H or S), and operation parameters (optional).

[0049] This reconstruction planning method directly obtains the minimum set of operations between the current configuration and the target configuration through graph difference calculation, and then generates a deterministic operation sequence by sorting according to three constraints. It does not rely on random search algorithms such as reinforcement learning that require a large number of training samples, resulting in higher reconstruction efficiency and predictable results. At the same time, it automatically identifies configuration changes through interface-level topology awareness, eliminating the need for manual reconfiguration of control parameters. In deep reconstruction, the system automatically identifies end-module replacements and adapts them to the control strategy.

[0050] The present invention also provides a reconfigurable modular robot comprising multiple modules belonging to different categories.

[0051] The categories are divided into five types according to their functional roles and topological positions, including core structures, degree-of-freedom joints, drive integrated links, end effectors, and functional accessories.

[0052] Each interface of each module is configured with a four-layer interface contract description, which includes interface level declaration parameters, mechanical coupling parameters, electrical transmission parameters, and communication protocol parameters.

[0053] Both ends of the joint of the degree of freedom adopt high load-bearing capacity interfaces.

[0054] In the drive integrated linkage, the first linkage uses a high load-bearing interface at the near end and a standard interface at the far end, serving as a bridging module between the two interfaces. The remaining linkages use standard interfaces at both ends.

[0055] The interface surfaces connecting adjacent modules satisfy the compatibility of the interface level declaration parameters, mechanical coupling parameters, electrical transmission parameters, and communication protocol parameters.

[0056] The end effector includes a wheel module and a wheel-leg module, both of which implement a standard-level interface contract and can be interchangeably connected to the remote standard-level interface surface of the drive integrated linkage, enabling the robot to switch between wheel-leg mode and wheeled mobile chassis mode.

[0057] This robot adopts a unified standard of five-type module system and two-level four-layer interface contract. Any module that conforms to the standard can be automatically verified for compatibility and integrated by the system. The interface contract is decoupled from the physical implementation, which does not limit the space for hardware innovation. The bridging law of the Class III first link realizes the seamless connection between the high load area and the lightweight end effector area. The standard-level interface contract of the end effector realizes the rapid interchange of functional modules.

[0058] Compared with the prior art, the present invention has the following advantages: (1) Achieving independence and interface symmetry: The interface contract specification is completely decoupled from the specific physical implementation. Any interface form that satisfies the contract can be included in the framework, without limiting the space for hardware innovation. The role field only declares the topology direction without distinguishing between mechanical active and passive. The same interface surface can assume the upstream or downstream role as needed, eliminating the limitation on the arbitrariness of topology reconstruction caused by the asymmetry of active and passive interfaces in the existing scheme.

[0059] (2) Two-level interfaces precisely match load distribution: high load-bearing level interfaces are concentrated in the high load position near the torso, while standard level interfaces cover the end lightweight scenario, taking into account both the system structural strength and the low cost standardization of the end module.

[0060] (3) Systematization of bridging rules: The bridging rules from the high load-bearing level to the standard level of the first link of Class III provide a systematic principle for the design of new limb configurations, reducing design freedom and error rate.

[0061] (4) Automatic topology transformation identification: In deep reconstruction, the system automatically identifies configuration changes through interface-level topology perception, without the need to manually reconfigure control parameters.

[0062] (5) Eliminate professional barriers: Configuration generation, compatibility verification, and refactoring planning can all be automated, and non-professionals can obtain a complete solution by describing task requirements.

[0063] (6) Scalability: The module library can be dynamically expanded. New modules only need to provide four-layer interface contract description files without modifying the configuration to generate the core logic of the system. Attached Figure Description

[0064] Figure 1This is a flowchart of a configuration generation method for a reconfigurable modular robot system provided in Embodiment 1 of the present invention.

[0065] Figure 2 This is a diagram of the four-layer parameter data structure for the interface contract.

[0066] Figure 3 This is a flowchart of the four-step compatibility verification process.

[0067] Figure 4 The overall flowchart for the configuration generation method shows the data flow relationship between the module library, task requirement inputs, and target configuration outputs.

[0068] Figure 5 A schematic diagram illustrating the four steps of the reconstructed planning method.

[0069] Figure 6 This is a schematic diagram showing the configuration of the dual-arm, four-wheeled legged robot in Example 1.

[0070] Figure 7 This is a schematic diagram of the reconstruction plan from a four-wheeled leg configuration to a wheeled mobile chassis configuration in Example 2. Detailed Implementation

[0071] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. The following embodiments are for illustrative purposes only and should not be considered as limiting the scope of the invention. Embodiment 1 details the complete implementation process of the configuration generation method, and Embodiment 2 details the complete implementation process of the reconstruction planning method.

[0072] Example 1: Configuration Generation of a Dual-Arm, Four-Wheel Legged Robot This embodiment takes industrial site inspection and material handling tasks as an example, combined with Figures 1 to 4 and Figure 6 This section details the specific implementation process of the configuration generation method for the reconfigurable modular robot system of the present invention. For example... Figure 1 As shown, the configuration generation method for this reconfigurable modular robot system specifically includes: Step S101: Establish a module classification system and interface contract description; like Figure 2 As shown, each interface of each module is configured with a four-layer interface contract description, including interface level declaration parameters, mechanical coupling parameters, electrical transmission parameters, and communication protocol parameters. The module categories, interface configurations, and interface levels required in this embodiment are shown in Table 1 below: Table 1 Classification Table

[0073] A four-layer interface contract description file is created for each interface face of each module and stored in the module library in JSON Schema format. Taking the distal interface face of the hip module (i.e., the interface face connecting to the proximal end of the thigh module) as an example, its interface contract declaration is as follows: Level 1 interface hierarchy declaration parameters: tier="H", role="distal"; Second-layer mechanical coupling parameters: Coupling type identifier = "H_flange_v1", rated load capacity = 800N, rated load torque = 160N·m, alignment tolerance level = "Level 2", connection direction set = "Axial"; Level 3 electrical transmission parameters: Rated operating voltage range = 18V-30V, Rated current = 10A, Power supply direction capability = "bidirectional", Hot-swap support flag = false, Electrical contact layout identifier = "P24"; Layer 4 communication protocol parameters: Communication protocol identifier = "CAN", communication bandwidth = 1Mbps, communication role = "slave", address allocation method = "dynamic allocation"; This step incorporates modules from different functional sources into a unified management framework through a five-category module classification system; it achieves decoupling of interface specifications and physical implementation through a two-level, four-layer interface contract; and it enables seamless connection between the high-load-bearing area and the lightweight end area under a unified framework through the bridging configuration from the high-load-bearing level to the standard level of the Class III first-section connecting rod.

[0074] Step S102: Receive task requirements, parse and extract the set of functional type requirements; Receive the task requirement "Industrial Site Inspection and Material Handling", parse and extract the set of functional type requirements: F = {(All-terrain mobility, 4), (Grasping operation capability, 2), (Environmental perception capability, 1), (Central control capability, 2), (Autonomous power supply capability, 1)}; Among them, the number 4 of all-terrain mobility corresponds to four independent leg chains, the number 2 of grasping operation capability corresponds to two independent arm chains, the number 2 of central control capability is used to meet the redundancy requirements of the control system, the environmental perception capability is provided by a perception module that combines lidar and camera, and the autonomous power supply capability is provided by a power module.

[0075] Construct a candidate module pool M_pool according to the method described in step (b). M_pool consists of two parts: a subset of functional carrying modules and a subset of structural support modules.

[0076] First, modules that can provide each type of function in F are searched in the module library and included according to their quantity requirements to obtain a subset of functional support modules: all-terrain mobility capability corresponding to Class IV end effector wheels ×4, grasping operation capability corresponding to Class IV end effector hands ×2, environmental perception capability corresponding to Class V functional accessory perception module ×1, central control capability corresponding to Class V functional accessory control module ×2, autonomous power supply capability corresponding to Class V functional accessory power module ×1, totaling 10 modules.

[0077] Secondly, according to the topological constraint rules of the five-module system, the structural and transmission modules necessary to support the above-mentioned functional modules are included, resulting in a subset of structural support modules: Type I core structure ×2 (torso ×1, hip base ×1), Type II degree-of-freedom joints ×7 (lumbar ×1, shoulder joint ×2, hip ×4), Type III first-section bridging link ×6 (upper arm ×2, thigh ×4), and Type III chain link ×6 (forearm ×2, lower leg ×4), totaling 21 modules.

[0078] The union of the two subsets forms the candidate module pool M_pool, which contains a total of 31 candidate modules.

[0079] This step allows non-specialists to obtain a complete solution simply by describing the task requirements, eliminating the reliance on the experience of professional engineers.

[0080] Step S103: Enumerate candidate module connection topologies and perform a four-step compatibility check; like Figure 3 As shown, this step sequentially performs interface level matching pre-verification, mechanical coupling compatibility verification, electrical compatibility verification, and communication protocol compatibility verification on any pair of adjacent module interfaces in each candidate configuration. Using the torso (Class I, T01) as the root node, and following robot topology constraints (Class I core structures as root nodes and intermediate hub nodes, Class II joints connecting the roots of each limb chain, Class III links extending, Class IV modules located at the end of the kinematic chain, and Class V modules attached to any standard-level interface surface), a depth-first search is used to enumerate the candidate module connection topology, generating a candidate configuration set. In this embodiment, the lower high-load-bearing interface surface of the torso T01 is connected to the hip base T02 via the waist module J01. The four high-load-bearing interface surfaces of the hip base T02 are respectively connected to the hip joints J04 to J07 of the four leg chains; the left and right shoulder high-load-bearing interface surfaces of the torso T01 are respectively connected to the shoulder joints J02 and J03, forming two arm chains; the standard-level interface surfaces of the torso T01 are attached to control, sensing, and power modules.

[0081] Taking the "hip → thigh" connection as an example, the four-step compatibility verification process is explained in detail: Step 1: Interface Level Matching Pre-verification. The hip module's interface is declared as tier="H", role="distal"; the thigh module's proximal interface is declared as tier="H", role="proximal". Both interface surfaces have the same tier (H) and complementary roles (distal and proximal). Step 1 passes. This step quickly eliminates incompatible pairings through low-cost pre-screening (e.g., directly rejecting high-load-bearing level pairings with standard level pairings), significantly reducing invalid verification overhead.

[0082] Step 2: Mechanical Coupling Compatibility Verification. The coupling type identifiers were all verified as "H_flange_v1" (matched); after parsing the task "handling 50kg of material," the task load requirements for the hip-to-thigh connection point are force ≥ 600N and torque ≥ 120N·m, which are satisfied with the rated load capacity = 800N and rated load torque = 160N·m in the hip module's remote interface contract; the alignment tolerance level is level 2 (meets deployment environment requirements); the connection direction set is "axial" (non-empty intersection). Step 2 passed.

[0083] Step 3: Electrical Compatibility Verification. The rated operating voltage range of the power supply side (hip module) = 18V-30V overlaps with the rated operating voltage range of the power receiving side (thigh module) = 20V-28V (the overlap is 20V-28V); the rated current of the power supply side = 10A meets the requirements of the power receiving side; the electrical contact layout identifier is "P24" (matched); the hot-plug support flags on both sides are both false. This connection does not involve hot-plugging, so this verification is skipped. Step 3 passed.

[0084] Step 4: Communication Protocol Compatibility Verification. Both parties' communication protocol identifiers are "CAN" (identical); the communication role combination is valid (both the hip module and thigh module are declared as "slave," with the Class V control module acting as the "master" for unified addressing on the same CAN bus; multiple slave combinations are valid); the communication bandwidth of 1Mbps meets the task requirements; the address allocation method is "dynamic allocation" (compatible). Step 4 passed.

[0085] All four verification steps passed, confirming that the "hip → thigh" interface is compatible with the contract.

[0086] Taking the "lower leg → wheel foot" connection as an example: Step 1 verifies that all tiers are of standard level, and the roles are complementary between distinct and proximal; the subsequent three verification steps all pass. Contract compatibility is determined.

[0087] Taking the "hip → hand" connection as an example: Step 1 checks whether the tier is high load-bearing level or standard level (which is different), directly determines that they are incompatible, and skips the subsequent three steps.

[0088] This step involves four automated verification steps. The system can automatically determine whether any two module interfaces can be connected without manual judgment. The first step of pre-verification effectively filters incompatible pairings, avoiding unnecessary computational overhead in the subsequent three steps.

[0089] Step S104: Functional integrity verification; Perform functional integrity verification on each candidate configuration that passes the four-step validation. Iterate through each functional requirement f in F. i =(c i q i The module list of candidate configurations can provide functional type c. i The number of modules is checked to ensure that the number is not less than the required number q. i If all functional requirements in F are met, the verification passes. If any functional requirement has fewer modules than its required quantity q, the verification fails. i If the candidate configuration is invalid, then the candidate configuration is deemed invalid.

[0090] For example, candidate configuration P1 only connects three leg chains when enumerating the leg chain topology. The number of wheel-foot modules that can provide all-terrain mobility in its module list is 3, which is less than the number of 4 required for this function in F. The functional integrity verification fails, and it is determined to be an invalid configuration and does not enter the selection range of step S105.

[0091] In this embodiment, the number of functional modules in the remaining candidate configurations is not less than the corresponding number requirement in F, and the verification is successful.

[0092] Candidate configurations that pass the four-step verification and functional integrity verification are defined as valid configurations.

[0093] This step ensures that the generated configuration is not only interface-compatible but also fully functional and capable of actually performing the target task.

[0094] Step S105: Select the target configuration and output it.

[0095] like Figure 6 As shown, the target configuration is selected from the valid configurations based on the optimization objective of "minimum total number of modules". The system filters out the configuration with the fewest modules from multiple valid configurations and finally outputs the configuration of the dual-arm, four-wheeled, legged robot, which has a total of 31 modules and 30 connecting edges, and outputs the module list and assembly sequence of this configuration.

[0096] The assembly sequence (31 steps in total, consisting of 1 base installation step and 30 interface connection steps, corresponding one-to-one with the 30 connection edges in the configuration topology diagram) includes the following for each step: operation type (installation or connection), operation object (specific module ID and corresponding interface face number), interface level identifier (high load-bearing level or standard level), and operation parameters (such as locking torque). The sequence is ordered according to dependency constraints: high load-bearing level connections are established before standard level connections that depend on them; the supported module is in place before the modules that depend on it are installed. Taking the first 5 steps of the assembly sequence as an example: Step 1: Install the torso module (Class I, ID: T01) and fix it to the base. Interface level: Not applicable. Step 2: Connect the upper surface of the waist module (Class II, ID: J01) to the lower interface surface of the torso module (high load-bearing level), with a locking torque of 50 N·m; Step 3: Connect the hip base module (Class I, ID: T02) to the lower end face of the waist module (high load-bearing level), with a locking torque of 50 N·m; Step 4: Connect the proximal end of the hip module (Class II, ID: J04) to the first interface surface (high load-bearing class) of the hip base module, with a locking torque of 50 N·m; Step 5: Connect the proximal end of the thigh module (Class III first section, ID: L03) to the distal interface surface of the hip module J04 (high load-bearing class), with a locking torque of 50 N·m; The assembly sequence can be executed directly by workers or automated assembly systems without the need for manual judgment of the order.

[0097] This step outputs directly executable assembly instructions, eliminating the manual conversion process between configuration schemes and actual assembly.

[0098] Example 2: Reconstruction Planning from Four-Wheel Leg Configuration to Wheeled Mobile Chassis Configuration This embodiment takes a dual-arm, four-wheeled legged robot (output configuration of embodiment one) reconstructed into a wheeled mobile chassis as an example, combined with... Figure 5 and Figure 7 This document details the specific implementation process of the reconfigurable modular robot system reconfiguration planning method of the present invention. This embodiment emphasizes the core innovative value of interface contracts enabling the interchangeability of different functional end-effector modules. The reconfiguration planning method for the reconfigurable modular robot system specifically includes: Step S201: Obtain the current configuration topology map and the target configuration topology map; like Figure 5 As shown in step 1, the current configuration topology graph G_current and the target configuration topology graph G_target are obtained. The configuration topology graph is a graph structure with each module in the robot system as a node and the interface connection relationship between modules as directed edges. Each node records the module ID and category, and each directed edge records the interface surface number and level (high load capacity level or standard level) of the connected interface surface.

[0099] Obtaining the current configuration topology map G_current: In this embodiment, G_current is automatically obtained through interface-level near-field communication. When modules are physically connected, the near-field communication chip at the interface automatically identifies the adjacent module IDs and interface level information, and constructs the current configuration topology map in real time. G_current contains 31 modules and 30 connection edges: torso (T01), hip base (T02), waist ×1 (J01), shoulder joint ×2 (J02-J03), hip ×4 (J04-J07), upper arm ×2 (L01-L02), thigh ×4 (L03-L06), forearm ×2 (L07-L08), lower leg ×4 (L09-L12), hand ×2 (E01-E02), wheel foot ×4 (E03-E06), control module ×2 (A01-A02), sensing module ×1 (A03), and power module ×1 (A04). Since the configuration topology is a tree structure, the number of connecting edges is equal to the number of module nodes minus one, which is 30.

[0100] Obtain the target configuration topology diagram G_target: G_target is output by the configuration generation method of Example 1. The target configuration is a wheeled mobile chassis: retaining 1 torso ×1, hip base ×1, waist ×1, hip ×4, thigh ×4, control module ×2, sensing module ×1, and power module ×1, for a total of 15 modules; installing 4 wheel modules at the standard interface at the distal end of the thigh; removing all 4 lower legs ×4, wheel feet ×4, hands ×2, forearms ×2, upper arms ×2, and shoulder joints ×2, for a total of 16 modules. G_target contains 19 modules (15 retained modules plus 4 newly added wheel modules) and 18 connecting edges.

[0101] This step automatically obtains the current configuration through topology awareness, eliminating the need for manual input; G_target can be directly output by the configuration generation method, realizing full-link automation from task requirements to target configuration and then to refactoring planning.

[0102] Step S202: Calculate the graph differences; like Figure 5 As shown in step 2, a graph structure comparison is performed between G_current and G_target, and the graph differences are calculated: Ops_remove = {Module nodes that exist in G_current but not in G_target} ∪ {Connections that exist in G_current but are broken in G_target} = {Disconnect wheel leg ×4 ← lower leg ×4 (standard level connection), remove wheel leg ×4; Disconnect lower leg ×4 ← thigh ×4 (standard level connection), remove lower leg ×4; Disconnect hand ×2 ← forearm ×2 (standard level connection), remove hand ×2; Disconnect forearm ×2 ← upper arm ×2 (standard level connection), remove forearm ×2; Disconnect upper arm ×2 ← shoulder joint ×2 (high load level connection), remove upper arm ×2; Disconnect shoulder joint ×2 ← torso (high load level connection), remove shoulder joint ×2}; Ops_add = {module nodes existing in G_target but not in G_current} ∪ {connection edges to be created in G_target} = {insert wheel modules × 4 (IV class, tier="S", role="proximal, implement standard-level interface contract); establish thigh remote standard-level interface} Wheel module × 4 connected}; In this embodiment, atomic operations are defined as four types: "disconnect", "remove", "insert", and "connect". Each set is counted using the same method: Ops_remove contains 16 disconnects and 16 removals, totaling 32 atomic operations; Ops_add contains 4 insertions and 4 connections, totaling 8 atomic operations; the merged set of operations contains a total of 40 atomic operations.

[0103] This step uses graph difference calculation to accurately identify the minimum set of differences between the current configuration and the target configuration, ensuring that the reconstruction operation is free of redundancy.

[0104] Step S203: Sort the operation set to generate an operation sequence that satisfies the constraints; like Figure 5 As shown in step 3, the operation set obtained by merging Ops_remove and Ops_add is sorted, and a topological sorting algorithm is used to generate an operation sequence that satisfies the following three constraints: Structural stability constraints: The topology graph remains connected after each operation (no suspended subgraphs are generated). Specifically, the standard-level connections at the end of the kinematic chain are disconnected first, and then dismantling is performed level by level towards the root node. Any module can only be disconnected after all its downstream modules have been removed; after each dismantling step, it is verified that the remaining topology graph is still connected. Accordingly, the dismantling sequence of the arm chain is hand → forearm → upper arm → shoulder joint, and the dismantling sequence of the leg chain is wheel foot → lower leg.

[0105] Interface level constraint: High-load-bearing level connections are established and confirmed to be stable before the standard-level connections that depend on them, and are disconnected after the standard-level connections that depend on them when dismantling. In this embodiment, the high-load-bearing level connections involved are torso ← shoulder joint ×2 and shoulder joint ← upper arm ×2. Therefore, the high-load-bearing level connections of the upper arm and shoulder joint can only be disconnected sequentially after all downstream standard-level connections such as the hand and forearm are disconnected.

[0106] Dependency constraint: The dependent connection is established before the connections that depend on it. The installation of the wheel module depends on the existence of the thigh remote standard interface, so ensure that the thigh module is in place before performing the wheel module installation.

[0107] This step uses three constraints to ensure that the robot structure remains stable throughout the reconstruction process, avoiding safety risks caused by topological breaks or sequence errors.

[0108] Step S204: Output the reconstruction operation sequence.

[0109] like Figure 5 As shown in step 4, the final output is a refactoring operation sequence (40 steps in total), each step including the operation type, object module ID and interface face number, and interface level identifier: Steps 1-4: Disconnect wheel feet ×4, target: the far end interface surfaces of wheel feet E03-E06 and lower legs L09-L12 (execute after safe power-off), interface level: standard level; Steps 5-8: Remove 4 wheel feet, objects: E03-E06; Steps 9-12: Disconnect 4 lower legs. Target: the distal interface surfaces of lower leg L09-L12 and thigh L03-L06. Interface level: Standard level. Steps 13-16: Remove 4 lower legs, objects: L09-L12; Steps 17-18: Disconnect hands x2, object: the distal interface surfaces of hands E01-E02 and forearms L07-L08, interface level: standard level; Steps 19-20: Remove 2 hands, objects: E01-E02; Steps 21-22: Disconnect forearms ×2, object: the distal interface surfaces of forearm L07-L08 and upper arm L01-L02, interface level: standard level; Steps 23-24: Remove 2 forearms, objects: L07-L08; Steps 25-26: Disconnect the upper arm ×2, object: the interface surface between the proximal end of the upper arm L01-L02 and the distal end of the shoulder joint J02-J03, interface level: high load-bearing level; Steps 27-28: Remove 2 upper arms, objects: L01-L02; Steps 29-30: Disconnect shoulder joints ×2, object: the proximal end of shoulder joints J02-J03 and the left and right shoulder interfaces of trunk T01, interface level: high load-bearing level; Steps 31-32: Remove shoulder joints ×2, objects: J02-J03; Steps 33-36: Insert wheel modules ×4, object: E07-E10, interface level: standard level; Steps 37-40: Connect 4 wheel modules to the standard interface of the thigh distal end. Object: Thigh L03-L06 distal interface → wheel module E07-E10, interface level: standard level (key verification: the interface contract declaration of the wheel module tier="S", role="proximal"; the parameters of the second to fourth layers meet the requirements of the thigh distal interface; all four verification steps pass).

[0110] After the above 40 steps are completed, the system automatically performs a four-step compatibility check on the new configuration and updates the configuration topology diagram, thereby enabling the control system to identify the new configuration. This verification and update process is completed automatically by the system, is not an atomic operation, and is not counted in the number of steps of the reconstruction operation sequence.

[0111] After reconstruction, the robot changed from a two-arm, four-wheeled leg configuration (19 degrees of freedom: waist ×1, shoulder joint ×2, hip ×4, and drive integrated linkage ×12) to a wheeled mobile chassis configuration (retaining a wheeled chassis with 9 degrees of freedom: waist ×1, hip ×4, and thigh ×4). The motion planner automatically switched control strategies. The wheel module and the original wheeled leg module both implemented standard-level interface contracts and can be interchangeably connected to the distal standard-level interface surface of the Class III drive integrated linkage (thigh).

[0112] This step outputs a sequence of reconfiguration operations that can be executed directly. Each operation is clearly marked with an interface level, making it easy for operators or automated systems to perform. Through interface-level topology awareness, the system automatically identifies configuration changes without the need for manual reconfiguration of control parameters.

[0113] The above embodiments are for illustrative purposes only and do not constitute a limitation on the scope of protection of this invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this invention should be included within the scope of protection of this invention. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A configuration generation method for a reconfigurable modular robot system, characterized in that, Includes the following steps: (a) Establish a module classification system and interface contract description: The robot modules are divided into five categories according to their functional roles and topological positions. The five categories include: core structure, degree-of-freedom joints, drive integrated links, end effectors and functional accessories; A four-layer interface contract description is established for each interface surface of each module. The interface contract description includes interface level declaration parameters, mechanical coupling parameters, electrical transmission parameters, and communication protocol parameters. (b) Receive task requirements, parse and extract the set of functional type requirements, search the module library for candidate modules that can provide each functional type in the set of requirements, and according to the topological constraint rules of the module classification system described in step (a), include the core structure, degree of freedom joints and drive integrated linkages necessary to support the candidate modules, and jointly construct the candidate module pool; (c) Enumerate the candidate module connection topology, generate a candidate configuration set, and for any pair of adjacent module interfaces in each candidate configuration, perform interface level matching pre-verification, mechanical coupling compatibility verification, electrical compatibility verification and communication protocol compatibility verification in sequence. If all four verifications pass, the interface is determined to be contract compatible; if all adjacent module interface pairs in the candidate configuration are determined to be contract compatible, the candidate configuration is determined to pass the verification. (d) Perform functional integrity verification on the candidate configurations that pass the verification. For each functional requirement in the set of functional type requirements parsed in step (b), count the number of modules in the candidate configurations that can provide that functional type, and verify whether the number is not less than the number requirement of that functional requirement. If all functional requirements are met, the functional integrity verification is passed. The candidate configurations that pass the four-step verification and the functional integrity verification are defined as valid configurations. (e) Select the target configuration from the effective configurations according to the optimization objective, and output the module list and assembly sequence of the configuration.

2. The configuration generation method for a reconfigurable modular robot system according to claim 1, characterized in that, The interface level declaration parameters include a level identifier field tier (layer, level) and a direction role field role (role). The tier value is "H" for high-bearing level or "S" for standard level, and the role value is "proximal", "distal" or "neutral". The interface level matching pre-verification includes: verifying that the tier field of the two interface surfaces is the same, and that the role field satisfies proximal and discrete docking or both are neutral.

3. The configuration generation method for a reconfigurable modular robot system according to claim 1, characterized in that, The optimization objectives include at least one of the following: minimum total number of modules, minimum system energy consumption, maximum redundancy, and minimum number of refactoring steps.

4. A reconfiguration planning method for a reconfigurable modular robot system, characterized in that, Includes the following steps: Obtain the current configuration topology graph G_current and the target configuration topology graph G_target. G_current is automatically obtained through topology awareness or entered by the user. G_target is output by the configuration generation method of the reconfigurable modular robot system as described in claim 1 or specified by the user. Calculate the graph difference between G_current and G_target to obtain the set of connections to be disconnected and modules to be removed (Ops_remove) and the set of modules to be added and connections to be established (Ops_add). Sort the operation set obtained by merging Ops_remove and Ops_add to generate an operation sequence that satisfies structural stability constraints, interface level constraints, and dependency constraints. The structural stability constraint means that the topology graph remains connected after each operation. The interface level constraint means that higher-level connections are established and confirmed to be stable before standard-level connections that depend on them, and are disconnected after standard-level connections that depend on them when being removed. The dependency constraint means that the dependent connection is established before the connection that depends on it. Output the reconstruction operation sequence, each step of which includes the operation type, object module ID, interface surface number, and interface level identifier.

5. The reconfiguration planning method for a reconfigurable modular robot system according to claim 4, characterized in that, It also includes a topology awareness step: when a module experiences a physical connection or disconnection event, it automatically obtains the IDs of adjacent modules and interface level information through interface-level near-field communication, and updates the current configuration topology graph G_current in real time.

6. A reconfigurable modular robot, characterized in that, It includes multiple modules belonging to different categories, which are divided into five categories according to their functional roles and topological positions. The five categories include core structures, degree-of-freedom joints, drive integrated linkages, end effectors, and functional accessories. Each interface surface of each module is configured with a four-layer interface contract description, which includes interface level declaration parameters, mechanical coupling parameters, electrical transmission parameters, and communication protocol parameters. Both ends of the joints of the degree of freedom adopt high load-bearing capacity interfaces; in the drive integrated linkage, the first link adopts a high load-bearing capacity interface at the near end and a standard interface at the far end, which acts as a bridging module between the two interfaces, and both ends of the remaining links adopt standard interface. The interface surfaces connecting adjacent modules satisfy the compatibility of the interface level declaration parameters, mechanical coupling parameters, electrical transmission parameters, and communication protocol parameters.

7. The reconfigurable modular robot according to claim 6, characterized in that, The end effector includes a wheel module and a wheel-leg module, both of which implement a standard-level interface contract and can be interchangeably connected to the remote standard-level interface surface of the drive integrated linkage, enabling the robot to switch between wheel-leg mode and wheeled mobile chassis mode.

Images