Service robot module matching method and device based on semantics

Abstract

The invention discloses a service robot module matching method and device based on semantics, and belongs to the technical field of artificial intelligence. The method comprises the following steps: a dynamic updating model of service robot function description: defining a semantic description framework of a function module; modeling and representing service functions by adopting a knowledge graph, and describing semantic features; service robot function module matching: calculating semantic similarity among modules of the service robot, and evaluating semantics by comprehensively considering multiple dimensions according to the semantic similarity; fuzzy matching is carried out to tolerate a certain degree of semantic difference; and modular integration and verification of the service robot: dynamically selecting and combining service modules according to user demands, considering semantic compatibility and interactivity among the service modules, and constructing the service robot meeting the demands. According to the method, efficient matching of all the modules can be well carried out, various customization schemes are obtained, optimized and updated, and personalized customization of the service robot is achieved.

Description

Technical Field

[0001] The present invention belongs to the technical field of artificial intelligence, and in particular relates to a semantic-based service robot module matching method and device. Background Art

[0002] With the popularization of modular design methods for robots, the number of various functional modules is increasing. These modules are different in terms of functions and performance indicators, which results in the increase in the number of modules while there are also many modules with slight differences.

[0003] Generally, when generating a service robot, it is necessary to use existing module data to splice and build a customized service robot that meets user needs. However, the existence of a large number of modules and many modules with slight differences requires repeated comparison, selection and matching according to needs when generating a service robot design plan, which is time-consuming and labor-intensive, seriously affecting the efficiency of service robot design and the quality of design results, and also restricting the development progress of service robots. Summary of the invention

[0004] The present invention aims to solve one of the technical problems in the above-mentioned related art at least to a certain extent.

[0005] To this end, the purpose of the present invention is to provide a semantic-based service robot module matching method and device, which can effectively match each module, obtain multiple customization schemes and optimize and update them, so as to realize personalized customization of the service robot.

[0006] In order to solve the above-mentioned technical problems, the present invention is achieved as follows:

[0007] An embodiment of the present invention provides a semantic-based service robot module matching method, the method comprising:

[0008] Build a dynamic update model for the service robot's functional description, including:

[0009] Define the semantic description framework of each functional module of the service robot; use the knowledge graph to model and represent the service functions and describe the semantic characteristics of the service functions;

[0010] Service robot functional module matching, including:

[0011] The module matching algorithm based on semantic similarity is adopted. The semantic similarity between modules of the service robot is calculated first, and the semantics is evaluated by comprehensively considering multiple dimensions according to the semantic similarity. Then fuzzy matching is performed, and a certain degree of semantic difference is tolerated to improve the flexibility of module matching.

[0012] Modular integration and verification of service robots, including:

[0013] Dynamically select and combine service modules according to user needs, consider the semantic compatibility and interactivity between service modules, and build a service robot that meets the needs.

[0014] In addition, the semantic-based service robot module matching method according to the present invention may also have the following additional technical features:

[0015] In some embodiments, the step of dynamically updating the model of the service robot function description includes:

[0016] S11. Define the domain and ontology of service robots;

[0017] S12, identifying entities of the service robot and the relationships between the entities;

[0018] S13. Construct a modular function or performance knowledge graph of a service robot;

[0019] S14. Expand and update the semantic description of the knowledge graph;

[0020] S15. Store the expanded and updated knowledge graph in a specific form.

[0021] In some embodiments, the step of matching the service robot function modules includes:

[0022] S21. Construct an interactive semantic matching framework based on knowledge graph;

[0023] S22. Determine fuzzy matching and extended query strategies.

[0024] In some embodiments, the steps of modular integration and verification of the service robot include:

[0025] S31. Generate a BOM list of each main module of the service robot according to user needs;

[0026] S32, confirming the compatibility of each module;

[0027] S33. Evaluate and optimize the service robot design plan corresponding to the BOM list.

[0028] In some embodiments, step S11 includes:

[0029] S111. Obtain input data, including core functions, performance indicators and related operation procedures of the service robot;

[0030] S112. Define key indicators: determine the performance parameters related to core functions;

[0031] S113. Create domain ontology based on core functions;

[0032] S114, Classification and attribute association: Classify different categories of functions and establish associations of relevant attributes for each functional category to ensure consistency of performance indicators across different categories;

[0033] Step S12 includes:

[0034] S121, obtaining input data, including the preliminary definition of each functional module in the service robot, and the core functions and performance indicators of the domain ontology determined in the previous steps;

[0035] S122, identifying entities in each functional module, including possible names and brief descriptions associated with each entity;

[0036] S123, using a large language model to analyze and extract the association relationship between entities;

[0037] Step S13 includes:

[0038] S131, integrating external data sources: extracting additional information related to the functional module from the external data source, and integrating the additional information with the existing entity;

[0039] S132, constructing a knowledge graph structure according to the entities, the associations between the entities, and the integrated information;

[0040] Step S14 includes:

[0041] S141, obtaining information available for extension;

[0042] S142, Semantic Expansion: Generate rich semantic information for each functional module through a large language model, including synonyms, similar derivatives, related attributes, usage suggestions and development trends, to enhance the expressive power of the knowledge graph;

[0043] S143. Data integration and update: Use a large language model to analyze and summarize all the information currently collected, and combine it with the existing knowledge graph to update the knowledge graph.

[0044] In some implementations, step S21 includes:

[0045] S211, obtaining query information from the user;

[0046] S212, Matching intent understanding: Use a large language model to parse the user's query information, extract key information and keywords, combine the context, clarify the intent and obtain more information;

[0047] S213, knowledge graph retrieval: retrieve information related to the user's query information from the knowledge graph, perform data matching, and extract the characteristics and performance of related modules;

[0048] S214, result cache: cache the matching results. When the user asks the same question again, query the cache first and return the previous result to improve the response speed.

[0049] In some embodiments, step S31 includes:

[0050] S311, obtaining user demand information and extracting keywords;

[0051] S312, knowledge graph query and matching: according to the needs of the user, the knowledge graph is used to retrieve relevant modules or stored components composed of multiple modules, and all modules and components that may meet the conditions, as well as their respective attributes, are identified;

[0052] S313, filtering and prioritizing: filtering the retrieved modules and components according to the filtering conditions, and adjusting the priorities of the selected modules and components according to the user's past preferences shown by historical data;

[0053] S314, generating a preliminary bill of materials according to the selected components and modules;

[0054] S315, Feedback Iteration Update: Regularly monitor and evaluate the quality of the generated BOM and provide feedback; based on the feedback information, dynamically update the knowledge graph and BOM generation logic to emphasize the components and preferences commonly used by users;

[0055] Step S32 includes:

[0056] S321, obtaining the description of each module in the initially generated bill of materials and the current knowledge graph;

[0057] S322. According to the bill of materials, construct large model prompt words one by one, and check compatibility in combination with the knowledge graph;

[0058] S323, evaluate compatibility and confirm the results;

[0059] S324. Iteratively update the knowledge graph and compatibility rules based on user feedback;

[0060] Step S33 includes:

[0061] S331. Obtain a description of a modular design scheme for a service robot; the number of the design schemes is multiple;

[0062] S332, semantic understanding and graph retrieval, generating evaluation and comparison results;

[0063] S333. Iteratively update the recommendation algorithm for the service robot design solution based on user preferences, needs and feedback.

[0064] In some implementations, the content of step S141 includes: the acquired information includes the constructed function or performance knowledge graph, module feedback information during use, and new data or technical progress; wherein the function or performance knowledge graph includes the entity, attribute and relationship information of each function module; the module feedback information during use includes user feedback and performance evaluation; the new data or technical progress includes newly released product specifications and related technical literature;

[0065] The functional modules preliminarily defined in step S121 include sensors, actuators, and controllers;

[0066] Possible names and brief descriptions of entities in step S122 include:

[0067] Distance sensor: used to measure the distance to obstacles; RGB camera: used for real-time image capture and processing; actuator motor: used to perform mechanical actions; control module: responsible for processing sensor data and controlling actuators;

[0068] The association relationship between the entities in step S123 includes:

[0069] Distance measuring sensor - control / controlled - control module; control module - dependent / dependent - actuator motor; RGB camera - control - control module.

[0070] In some of the embodiments, the content of step S322 includes: using a large language model to parse the user's query and extract key elements, including module type, connection method and possible compatibility issues; confirming the technical specifications, interfaces and compatibility data of the module; if there is a relationship definition, extracting relevant information for subsequent compatibility evaluation;

[0071] The contents of step S332 include: using a large language model to parse user input and extract key features and evaluation indicators; retrieving the performance and applicable scenarios of relevant components in the knowledge graph based on the extracted information, and evaluating the feasibility of each solution; querying the robot's working environment, sensor performance, and component compatibility to provide a more comprehensive evaluation.

[0072] An embodiment of the present invention also provides a semantic-based service robot module matching device, including a processor and a memory, wherein the memory stores a program, and is characterized in that when the processor runs the program on the memory, it can implement the content of the semantic-based service robot module matching method as described in any of the above items.

[0073] Compared with the prior art, the present invention has at least the following beneficial effects:

[0074] In the embodiment of the present invention, the semantic-based service robot module matching method provided extracts semantics and constructs a graph when describing (storing); when matching, it adopts the description function and performance of natural language, and realizes interactive module matching based on the large model + RAG framework; through semantic-based module combination and evaluation, multiple solutions that meet the needs are given, and sorting and optimization are performed; it is possible to perform efficient matching of various modules, obtain multiple customized solutions and optimize and update them, and realize personalized customization of service robots.

[0075] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0076] Figure 1 The present invention is a flowchart of a semantic-based service robot module matching method disclosed in one embodiment of the present invention. DETAILED DESCRIPTION

[0077] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0078] The embodiments of the present invention are described in detail below through specific embodiments and application scenarios in conjunction with the accompanying drawings.

[0079] See also Figure 1 As shown, in some embodiments of the present invention, a semantic-based service robot module matching method is provided, which mainly includes three parts: a dynamic update model of a semantic-based service robot function description, a semantic-based service robot function module matching, and a semantic-based service robot modular integration and verification. These three parts are described in detail below.

[0080] 1. Dynamic update model of service robot function description based on semantics

[0081] Define the semantic description framework of the service robot function module, including "semantic" related elements such as function / performance description (unstructured), input and output parameters (structured), preconditions (unstructured), and post-effects (unstructured). Use "knowledge graph" to model and represent service functions and describe the semantic characteristics of service functions. Specifically:

[0082] 1.1. Defining the Service Robot Domain and Ontology

[0083] Identify the core functions, capabilities and operational areas of service robots;

[0084] Create a domain ontology to define relevant categories (such as navigation, grasping, interaction, etc.) and attributes (such as speed, accuracy, etc.).

[0085] In some embodiments of the present invention, the step specifically includes:

[0086] Step 1: Obtain input. Input the core functions, performance indicators, and related operation processes of the service robot.

[0087] Step 2: Define key metrics. Identify performance parameters related to core functions.

[0088] Step 3: Create domain ontology.

[0089] Taking the navigation module of a service robot as an example, the domain ontology created here can include the following attributes:

[0090] Category: Navigation Module

[0091] Attributes: Speed: 3 m / s; Accuracy: 10 cm; Environmental adaptability: indoors and outdoors.

[0092] Step 4: Classification and attribute association. Classify the functions of different categories and establish the association of related attributes for each functional category. Ensure the consistency of performance indicators across different categories.

[0093] 1.2. Identifying entities and relationships of service robots

[0094] Identify entities of functional modules, create vertices and assign vertex names, such as sensors, actuators, controllers, etc.

[0095] Determine the relationship between entities and create edges, such as "control", "cooperation", "dependency", etc.

[0096] In some embodiments of the present invention, the step specifically includes:

[0097] Step 1: Obtain input. Obtain a preliminary definition of the functional modules contained in the service robot (e.g., sensors, actuators, controllers, etc.), as well as the core functions and performance indicators of the domain ontology determined in the previous step.

[0098] Step 2: Identify entities in functional modules. The functional module definition is analyzed using a large language model to identify specific module entities (vertex information) related to the service robot, including possible names and brief descriptions associated with each entity.

[0099] In some embodiments of the present invention, the following entities and function definitions are identified through a large language model:

[0100] Distance sensor: used to measure the distance to obstacles;

[0101] RGB camera: for real-time image capture and processing;

[0102] Actuator motor: used to perform mechanical actions;

[0103] Control module: responsible for processing sensor data and controlling actuators.

[0104] Step 3: Extract entity associations. Use a large language model to analyze the functional relationships between these entities (define edges between entities).

[0105] In some embodiments of the present invention, the extracted functional relationships include:

[0106] Distance measuring sensor----control / controlled----control module;

[0107] Control module----depends / is depended on----executes motor;

[0108] RGB camera----control----control module.

[0109] 1.3. Constructing a modular function / performance knowledge graph for service robots

[0110] Semantically annotate the functions / performance of each module and use natural language to describe its functions and characteristics.

[0111] Integrate external data sources (such as technical manuals and user guides of robot modules) with the knowledge graph to enrich the description of the module.

[0112] In some embodiments of the present invention, the step specifically includes:

[0113] Step 1: Integrate external data sources. Extract additional information related to the functional module from external data sources and integrate this information with existing entities to enrich the description of the module. For example, extract specification parameters from technical manuals, including the description of the core functions and performance indicators of the domain ontology formed in the previous step.

[0114] Step 2: Construct the knowledge graph structure. Organize the information fused with semantic annotations and external data into the structure of the knowledge graph, and clarify the attributes of each module and the relationship between them. For example: organize and integrate the related entities and relationships constructed previously to form a complete knowledge graph that integrates the functional modules of the service robot.

[0115] In some embodiments of the invention, the entity comprises:

[0116] The characteristics of the distance measuring sensor include: working range 0.2m to 6m; accuracy ±1cm; working voltage 5V; power consumption 50mA; response time 15ms;

[0117] RGB camera, its features include: resolution 1920×1080; frame rate 30fps; field of view 90 degrees; connection method USB;

[0118] The actuator motor has the following characteristics: type is a DC motor; maximum speed is 300 rpm; torque is 0.5 Nm; rated voltage is 12V;

[0119] The control module has the following features: processor ARM Cortex-M4; memory 256KB; interfaces are I2C, SPI, and UART.

[0120] In some embodiments of the invention, the relationship includes:

[0121] Range finding sensor control control module;

[0122] ROB camera control module;

[0123] The control module relies on the actuator motor;

[0124] The distance measuring sensor affects the movement of the actuator motor.

[0125] 1.4. Extension and update of the semantic description of the module knowledge graph

[0126] Adapt to the dynamic changes of service robot modules (for example, use sensors to detect each module of the robot and expand based on SSN);

[0127] Expand semantically related synonyms and similar derivatives;

[0128] Adapt to the changes in the diverse relationships between modules of the service robot.

[0129] In some embodiments of the present invention, the step specifically includes:

[0130] Step 1: Get updated information. This includes the built function / performance knowledge graph (including entities, attributes, relationships, etc. of each functional module), module feedback information during use (such as user feedback, performance evaluation, etc.), new data or technical progress (such as newly released product specifications, related technical literature, etc.). For example:

[0131] User feedback: Users mainly complained that the current ultrasonic ranging sensors have insufficient performance in complex environments, especially the accuracy issues in foggy and hazy weather;

[0132] Parameter update: The latest laser ranging sensor has higher measurement accuracy and working range.

[0133] Step 2: Semantic expansion: Generate rich semantic information for each functional module through a large language model, including synonyms, related attributes, usage suggestions, and development trends, to improve the expressive power of the knowledge graph.

[0134] In some embodiments of the present invention, using a large language model to generate relevant semantic information for a ranging module includes:

[0135] Distance sensor:

[0136] Synonyms: distance measuring sensor, distance detector;

[0137] Related attributes: ultrasonic mode, laser mode;

[0138] Usage suggestion: It is recommended to use laser ranging sensor in complex environments to improve accuracy.

[0139] Step 3: Data integration and update. Use a large language model to analyze and summarize the collected feedback information. The large model can extract key points from the feedback and suggest how to improve the module description. Combine new technical information obtained from external data sources (such as new sensor specifications, performance improvements, etc.) with the existing knowledge graph.

[0140] In some embodiments of the invention, the entity comprises:

[0141] Ultrasonic distance measuring sensor, its features include: working range 0.2 meters to 6 meters; accuracy ± 1 cm; weakness is that it may cause measurement errors in haze environment;

[0142] Laser ranging sensor, its features include: working range 0.1m to 10m; accuracy ±0.5cm; working voltage 5V; power consumption 30mA;

[0143] In some embodiments of the invention, the relationship includes:

[0144] Ultrasonic distance measuring sensor control control module;

[0145] Laser rangefinder sensor control module;

[0146] The control module relies on the actuator motor;

[0147] The ultrasonic distance sensor influences the movement of the actuator motor.

[0148] 1.5. Storage of module knowledge graph

[0149] The knowledge graph is stored in RDF format, storing the names and characteristics of each robot module and the relationships between each module through the relationship between fulcrums and edges to facilitate the integration and query of distributed data.

[0150] 2. Semantic-based service robot function module matching algorithm

[0151] The module matching algorithm based on semantic similarity is used to calculate the semantic similarity between modules of the service robot. Comprehensive "semantic" evaluation is performed by considering multiple dimensions such as service functions, performance parameters, input and output, preconditions and postconditions. Fuzzy matching is supported, a certain degree of semantic differences is tolerated, and the flexibility of module matching is improved. Specifically:

[0152] 2.1. Interactive semantic matching framework based on knowledge graph

[0153] Consider adopting the RAG method of large model + graph, providing an interactive query interface based on natural language, and supporting users to conduct multi-round conversational queries;

[0154] Based on the natural language input by the user, relevant information is extracted, and based on the requirements for the service robot performance provided by the user in each round, a semantic flow is formed. The edge labeled graph is traversed and queried in the form of a flow, and then fed back to the user to save the semantic flow.

[0155] In some embodiments of the present invention, the step specifically includes:

[0156] Step 1: Get the query requirements. The user enters the question in natural language, and the system needs to be able to understand the user's intention and the context of the query:

[0157] User query: Which distance sensor is more suitable in foggy weather? Higher accuracy is required;

[0158] Step 2: Match intent understanding. Use a large language model to parse user queries, extract key information and keywords, and combine the context to clarify intent and obtain more information. For example:

[0159] Context: Haze weather

[0160] Requirement: Higher ranging accuracy

[0161] Step 3: Knowledge graph retrieval. Retrieve relevant information from the knowledge graph, combining information retrieval and text generation, matching the user's query with the data in the knowledge graph, and extracting the characteristics and performance of related modules.

[0162] In some embodiments of the present invention, the above search results may be:

[0163] The accuracy of ultrasonic distance sensors is ±1 cm, which may cause errors in foggy weather. The accuracy of laser distance sensors is ±0.5 cm, and they perform better in complex weather conditions.

[0164] Step 4: Result caching. When the user asks the same question again, the system will first query the cache. After finding a matching cache record, it will directly return the previous result to improve the response speed.

[0165] 2.2 Fuzzy matching and extended query strategy

[0166] For queries that cannot be fully matched, semantic-based fuzzy matching technology is used to relax matching conditions and improve query coverage;

[0167] Automatically expand the query scope based on the query results and provide more relevant functional module suggestions;

[0168] Dynamically adjust query strategies based on user feedback to improve the module's query accuracy and user experience.

[0169] 3. Semantic-based modular integration and verification method for service robots

[0170] Dynamically discover, select and combine service modules according to user needs to build a service robot that meets the needs. Consider the semantic compatibility and interactivity between service modules, and automatically generate the BOM list of each major module of the service robot. Evaluate and optimize different BOM lists in multiple dimensions (price, performance, function, etc.) to provide a reference for design selection. Specific (EBOM-PBOM-MBOM-SBOM-SerBOM):

[0171] 3.1. Automatic BOM generation

[0172] After traversing the knowledge graph and finding the modules of the robot, the composition of the service robot is generated according to the relationship between nodes and edges. According to the composition of the service robot, the drawings are automatically called out, and according to the drawing model, the EBOM of the main modules of the robot is automatically generated using the program. In robot design, the BOM is generated as EBOM, and the performance is subsequently compared based on the EBOM.

[0173] In some embodiments of the present invention, the step specifically includes:

[0174] Step 1: Receive and parse user input. The user submits product design requirements, and the large language model is used to understand and parse the user requirements and extract keywords. For example:

[0175] User input: Design an intelligent robot with ultrasonic ranging function, which requires sensors, control modules, power supplies and actuators.

[0176] Step 2: Knowledge graph query and matching. Based on the user's needs, the knowledge graph is used to retrieve modules and components related to the proposed project (such as ultrasonic ranging sensors, control modules, etc.). All components that may meet the conditions are identified, including the properties of each component (such as price, type, availability, etc.). For example, the system obtains modules related to "temperature monitoring" and "automatic obstacle avoidance" through the knowledge graph:

[0177] Temperature and humidity sensor, ultrasonic ranging sensor (for obstacle avoidance), motor drive module (wheels), power module (battery).

[0178] Step 3: Component screening and prioritization. Filter the retrieved components according to the filtering conditions (such as performance requirements, cost constraints, compatibility, etc.) to determine the appropriate components. Use historical data to consider the user's past preferences and adjust the priority of the components.

[0179] In some embodiments of the present invention, the filtering conditions include:

[0180] Temperature and humidity sensor: model, price, accuracy;

[0181] Ultrasonic distance sensors: models, prices, range;

[0182] Motor: DC motor or stepper motor;

[0183] Batteries: type, parameters, etc.

[0184] Step 4: Generate a preliminary bill of materials based on the selected components and modules. Including: component name, quantity, description, unit price, etc. For example:

[0185] Table 1

[0186] Component Name quantity describe unit price Temperature and humidity sensor 1 Used to monitor ambient temperature and humidity 5 Ultrasonic distance sensor 1 For obstacle detection and avoidance 10 DC Motor 2 Driving the car 15 Power Module 1 Provide the required voltage and current for the car 8 Motor drive module 1 Control the acceleration and deceleration of the motor 12

[0187] Step 5: Feedback and iterative updates. Present the generated BOM to the user in an easy-to-understand format, which can be text, table, or other interactive forms. Based on user feedback, dynamically update the knowledge graph and the logic of BOM generation to emphasize the user's commonly used components and preferences. Regularly monitor and evaluate the quality of the generated BOM, and optimize the model and graph when necessary.

[0188] 3.2. Compatibility confirmation of service robot modules

[0189] According to the components of the robot service module in the EBOM and its semantic description in the knowledge graph, the keywords of each module EBOM are extracted to form a module-based matrix.

[0190] Compare the differences between the keywords of each module, traverse the knowledge graph, focus on the relevant keywords in the knowledge graph, and comprehensively compare the labels and information of each module used to confirm whether there are any incompatibilities between modules;

[0191] After confirming the compatibility between modules, confirm the EBOM and store the EBOM.

[0192] In some embodiments of the present invention, the step specifically includes:

[0193] Step 1: Get input: The description of each module in the initially generated BOM and the aforementioned knowledge graph.

[0194] Step 2: According to the BOM list, build large model prompt words one by one, and check compatibility in combination with the knowledge graph. Use the large language model to parse the user's query and extract the key elements: module type, connection method, and possible compatibility issues. In the knowledge graph, retrieve the relevant module information based on the information entered by the user, and confirm the technical specifications, interfaces, and compatibility data of the module. If there is a relationship definition (such as connection method, data transmission protocol, etc.), extract the relevant information for subsequent compatibility evaluation. For example: retrieve the interface standard of the Arduino controller and the technical parameters of the HC-SR04 sensor in the knowledge graph:

[0195] Arduino's GPIO (digital pins) and power input (5V);

[0196] Interface requirements for HC-SR04: Use two digital pins for trigger and echo signals.

[0197] Step 3: Evaluate compatibility and confirm results. Combined with the query results, the requested modules are compared to determine whether their technical parameters such as interface, communication protocol, voltage standard, etc. match. If different modules are involved, the system will analyze their interdependencies and potential conflicts. The evaluation results will be generated into a natural language response to clearly explain the compatibility status.

[0198] Step 4: Feedback iteration and update. After obtaining user feedback, if new compatible information is found or valuable information is provided by users, the knowledge graph and compatibility rules are updated in a timely manner.

[0199] 3.3 Evaluation and comparison of service robot design schemes

[0200] Based on EBOM, generate PBOM, MBOM, BBOM and after-sales BOM, and integrate the BOM of each module into the overall design BOM of the service robot;

[0201] Based on the saved semantic flow of user requirements and combined with additional information in the knowledge graph, such as process conditions, transportation costs, characteristics of each component, and the quality of material selection, corresponding scores are formed, a ranking table is generated, and reasons are listed to allow users to make choices.

[0202] In some embodiments of the present invention, the step specifically includes:

[0203] Step 1: Get input. Description of multiple service robot modular design schemes. Including: functional description of each scheme, expected environment, technical parameters (such as processor type, sensor type, communication protocol, etc.), and budget constraints. For example:

[0204] Solution A: Smart cleaning robot A, sensor: LIDAR, budget: $600, working range: 150 square meters;

[0205] Solution B: Smart cleaning robot B, sensors: camera and infrared, budget: $800, working range: 300 square meters;

[0206] Solution C: Smart cleaning robot C, sensors: ultrasonic, temperature sensor, budget: $700, working range: 200 square meters.

[0207] Step 2: Semantic understanding and graph retrieval to generate evaluation and comparison results. Use a large language model to parse user input and extract key features and evaluation indicators (such as functions, scope of work, budget, etc.). Retrieve the performance and applicable scenarios of relevant components in the knowledge graph based on the extracted information to evaluate the feasibility of each solution. Query data such as the robot's working environment, sensor performance, component compatibility, etc. to provide a more comprehensive evaluation. For example:

[0208] Option A:

[0209] Advantages: LIDAR has high accuracy and is suitable for cleaning tasks; low cost;

[0210] Disadvantages: Limited adaptability to complex environments.

[0211] Option B:

[0212] Advantages: Capable of video surveillance, suitable for security applications; wide working range;

[0213] Disadvantages: higher price and high maintenance cost.

[0214] Option C:

[0215] Advantages: Strong adaptability to medical environments, equipped with ultrasonic and temperature sensors.

[0216] Step 3: Feedback selection and update. Provide more personalized recommendations based on user preferences and needs. Adjust evaluation criteria and recommendation results based on user feedback to continuously optimize the recommendation algorithm.

[0217] For parts of the present invention that are not described in detail, reference may be made to the prior art in the art or technologies known to those skilled in the art.

[0218] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation modes, which are merely illustrative rather than restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are within the protection of the present invention.

Claims

1. A semantic-based service robot module matching method, characterized in that: The method comprises: Build a dynamic update model for the service robot's functional description, including: Define the semantic description framework of each functional module of the service robot; use the knowledge graph to model and represent the service functions and describe the semantic characteristics of the service functions; Service robot functional module matching, including: The module matching algorithm based on semantic similarity is adopted. The semantic similarity between modules of the service robot is calculated first, and the semantics is evaluated by considering multiple dimensions according to the semantic similarity. Then fuzzy matching is performed, and a certain degree of semantic difference is tolerated to improve the flexibility of module matching. Modular integration and verification of service robots, including: Dynamically select and combine service modules according to user needs, consider the semantic compatibility and interactivity between service modules, and build a service robot that meets the needs.

2. The semantic-based service robot module matching method according to claim 1, characterized in that: The steps of dynamically updating the model of the service robot function description include: S11. Define the domain and ontology of service robots; S12, identifying entities of the service robot and the relationships between the entities; S13. Construct a modular function or performance knowledge graph of a service robot; S14. Expand and update the semantic description of the knowledge graph; S15. Store the expanded and updated knowledge graph in a specific form.

3. The semantic-based service robot module matching method according to claim 1, characterized in that: The steps of matching the service robot function modules include: S21. Construct an interactive semantic matching framework based on knowledge graph; S22. Determine fuzzy matching and extended query strategies.

4. The semantic-based service robot module matching method according to claim 1, characterized in that: The steps for modular integration and verification of service robots include: S31. Generate a BOM list of each main module of the service robot according to user needs; S32, confirming the compatibility of each module; S33. Evaluate and optimize the service robot design plan corresponding to the BOM list.

5. The semantic-based service robot module matching method according to claim 2, characterized in that: Step S11 includes: S111. Obtain input data, including the core functions, performance indicators and related operation procedures of the service robot; S112. Define key indicators: determine the performance parameters related to core functions; S113. Create domain ontology based on core functions; S114, Classification and attribute association: Classify different categories of functions and establish associations of relevant attributes for each functional category to ensure consistency of performance indicators across different categories; Step S12 includes: S121, obtaining input data, including the preliminary definition of each functional module in the service robot, and the core functions and performance indicators of the domain ontology determined in the previous steps; S122, identifying entities in each functional module, including possible names and brief descriptions associated with each entity; S123, using a large language model to analyze and extract the association relationship between entities; Step S13 includes: S131, integrating external data sources: extracting additional information related to the functional module from the external data source, and integrating the additional information with the existing entity; S132, constructing a knowledge graph structure according to the entities, the associations between the entities, and the integrated information; Step S14 includes: S141, obtaining information available for extension; S142, Semantic Expansion: Generate rich semantic information for each functional module through a large language model, including synonyms, similar derivatives, related attributes, usage suggestions and development trends, to enhance the expressive power of the knowledge graph; S143. Data integration and update: Use a large language model to analyze and summarize all the information currently collected, and combine it with the existing knowledge graph to update the knowledge graph.

6. The semantic-based service robot module matching method according to claim 3, characterized in that: Step S21 includes: S211, obtaining the user's query information; S212, Matching intent understanding: Use a large language model to parse the user's query information, extract key information and keywords, combine the context, clarify the intent and obtain more information; S213, knowledge graph retrieval: retrieve information related to the user's query information from the knowledge graph, perform data matching, and extract the characteristics and performance of related modules; S214, result cache: cache the matching results. When the user asks the same question again, query the cache first and return the previous result to improve the response speed.

7. The semantic-based service robot module matching method according to claim 4, characterized in that: Step S31 includes: S311, obtaining user demand information and extracting keywords; S312, knowledge graph query and matching: according to the needs of the user, the knowledge graph is used to retrieve relevant modules or stored components composed of multiple modules, and all modules and components that may meet the conditions, as well as their respective attributes, are identified; S313, filtering and prioritizing: filtering the retrieved modules and components according to the filtering conditions, and adjusting the priorities of the selected modules and components according to the user's past preferences shown by historical data; S314, generating a preliminary bill of materials according to the selected components and modules; S315, Feedback Iteration Update: Regularly monitor and evaluate the quality of the generated BOM and provide feedback; based on the feedback information, dynamically update the knowledge graph and BOM generation logic to emphasize the components and preferences commonly used by users; Step S32 includes: S321, obtaining the description of each module in the initially generated bill of materials and the current knowledge graph; S322. According to the bill of materials, construct large model prompt words one by one, and check compatibility in combination with the knowledge graph; S323, evaluate compatibility and confirm the results; S324. Iteratively update the knowledge graph and compatibility rules based on user feedback; Step S33 includes: S331. Obtain a description of a modular design scheme for a service robot; the number of the design schemes is multiple; S332, semantic understanding and graph retrieval, generating evaluation and comparison results; S333. Iteratively update the recommendation algorithm for the service robot design solution based on user preferences, needs and feedback.

8. The semantic-based service robot module matching method according to claim 5, characterized in that: The content of step S141 includes: the acquired information includes the constructed function or performance knowledge graph, module feedback information during use, and new data or technical progress; wherein the function or performance knowledge graph includes the entity, attribute and relationship information of each function module; the module feedback information during use includes user feedback and performance evaluation; the new data or technical progress includes newly released product specifications and related technical literature; The functional modules preliminarily defined in step S121 include sensors, actuators, and controllers; Possible names and brief descriptions of entities in step S122 include: Distance sensor: used to measure the distance to obstacles; RGB camera: used for real-time image capture and processing; actuator motor: used to perform mechanical actions; control module: responsible for processing sensor data and controlling actuators; The association relationship between the entities in step S123 includes: Distance measuring sensor - control / controlled - control module; control module - dependent / dependent - actuator motor; RGB camera - control - control module.

9. The semantic-based service robot module matching method according to claim 7, characterized in that: Step S322 includes: using a large language model to parse the user's query and extract key elements, including module type, connection method, and possible compatibility issues; confirming the technical specifications, interfaces, and compatibility data of the module; if there is a relationship definition, extracting relevant information for subsequent compatibility evaluation; The contents of step S332 include: using a large language model to parse user input, extract key features and evaluation indicators; retrieving the performance and applicable scenarios of relevant components in the knowledge graph based on the extracted information, and evaluating the feasibility of each solution; querying the robot's working environment, sensor performance, and component compatibility to provide a more comprehensive evaluation.

10. A semantic-based service robot module matching device, comprising a processor and a memory, wherein a program is stored in the memory, characterized in that: When the processor runs the program on the memory, it can implement the content of the semantic-based service robot module matching method as described in any one of claims 1 to 9.

Images