Service calling method, electronic equipment, medium and program product

Abstract

The invention provides a service calling method, electronic equipment, a medium and a program product. The method comprises the following steps: registering a target service to obtain service description information of the target service, issuing the service description information by a server, generating a service calling request by a client based on the service description information, and sending the service calling request to the server. The server side can convert the service calling request into the service calling message conforming to the message specification of the robot operating system based on the conversion rule, and sends the service calling message to the service node providing the target service, so that calling of the target service is achieved.

Description

Technical Field

[0001] This specification relates to the field of artificial intelligence technology, and more particularly to a service invocation method, electronic device, medium, and program product. Background Technology

[0002] In recent years, artificial intelligence technology has developed rapidly, and the combination of Model Context Protocol (MCP) and Large Language Model (LLM) has been widely used in the development of app-level intelligent agents. However, the field of embodied intelligent robots faces new challenges. Robots are usually developed based on robot operating system frameworks, and developers need to make intrusive modifications to the original robot function package source code to adapt to the MCP protocol, which increases the development complexity. Summary of the Invention

[0003] In view of the above, one or more embodiments of this specification provide the following technical solutions:

[0004] According to a first aspect of one or more embodiments of this specification, a service invocation method is proposed, applied to a server, the server being communicatively connected to a robot with a robot operating system deployed thereon and a client based on a model context protocol, the robot including at least one service node for providing services based on the robot operating system, and the client being able to communicate with a large language model based on the model context protocol; the method includes:

[0005] The system receives a service call request from the client for a target service. The service call request is based on the model context protocol and is generated based on service description information pre-published by the server. The service description information is obtained by registering the target service and is used to describe the generation rules of the service call request and the function of the target service.

[0006] Obtain the conversion rule corresponding to the target service, and convert the service call request into a service call message that conforms to the message specification of the robot operating system based on the conversion rule. The conversion rule is used to define the conversion method of converting the service call request into the service call message.

[0007] The service call message is sent to the target service node that provides the target service among the at least one service node to invoke the target service.

[0008] According to a second aspect of one or more embodiments of this specification, a service invocation method is proposed, applied to a client based on a Model Context Protocol (MTP). The client is capable of communicating with a large language model based on the MTP and communicating with a server. The server also communicates with a robot equipped with a robot operating system. The robot includes at least one service node for providing services based on the robot operating system. The method includes:

[0009] Obtain the service description information pre-published by the server. The service description information is obtained by registering the target service and is used to describe the generation rules of the service call request and the function of the target service.

[0010] A service invocation request for the target service is generated based on the service description information; the service invocation request is a request based on the model context protocol.

[0011] The service call request is sent to the server, so that the server converts the service call request into a service call message conforming to the message specification of the robot operating system based on the conversion rule corresponding to the target service, and sends the service call message to the target service node that provides the target service among the at least one service node to call the target service; the conversion rule is used to define the conversion method of converting the service call request into the service call message.

[0012] As can be seen from the above embodiments, this specification describes a method where the target service is registered to obtain its service description information. The server then publishes this service description information, and the client generates a service call request based on the description information and sends it to the server. The server can convert the service call request into a service call message conforming to the message specification of the robot operating system based on conversion rules, and send the message to the service node providing the target service, thereby enabling the invocation of the target service. This method avoids intrusive modifications to the original robot function package source code, reducing development complexity. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of a system architecture provided in an exemplary embodiment.

[0014] Figure 2 This is a flowchart of a service invocation method applied to a server, provided as an exemplary embodiment.

[0015] Figure 3 This is a schematic diagram of a data interaction process provided in an exemplary embodiment.

[0016] Figure 4This is a flowchart of a service invocation method applied to a client, provided as an exemplary embodiment.

[0017] Figure 5 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0018] Figure 6 This is a block diagram of a service invocation device applied to a server, provided in an exemplary embodiment.

[0019] Figure 7 This is a block diagram of a service invocation device applied to a client, provided in an exemplary embodiment. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0021] Figure 1 This is a schematic diagram of a system architecture provided in an exemplary embodiment. For example... Figure 1 As shown, the system may include a server 102, a client 104, and a robot 106. The client 104 can be a client based on the Model Context Protocol (MCP). The Model Context Protocol is an open protocol that standardizes how applications provide context to a large language model. The client 104 can invoke the large language model 108. Specifically, the client 104 can organize various input information (such as user input information, knowledge base retrieval information, etc.) into prompt information based on the MCP protocol and input it into the large language model 108.

[0022] A robot operating system, such as ROS2 (Robot Operating System 2), can be deployed on robot 106. Robot 106 may include at least one service node, each providing services based on the robot operating system. For example, the navigation service node is responsible for path planning and target point navigation; the control service node precisely manipulates the robot's joints or movement mechanisms to ensure the robot moves along the planned path; the perception service node processes visual or voice input, extracts key data, and transmits it to other nodes to assist in environmental recognition and task execution; the decision-making service node integrates perception information and service requests to help the robot complete complex task planning, such as obstacle avoidance and behavior selection.

[0023] The server 102 can act as a bridge between the client 104 and the robot 106, communicate with the client 104 based on the model context protocol, send messages conforming to the message specifications of the robot operating system to the robot 106, and obtain messages returned by the robot 106.

[0024] In the above architecture, server 102, client 104, and robot 106 work together. Client 104 is responsible for organizing various input information into prompts and calling the large language model 108. Robot 106, as the execution carrier of embodied intelligence, completes tasks through the operating system. However, in related technologies, the combination of Model Context Protocol (MCP) and large language model is widely used in the development of APP-level intelligent agents. Robots are usually developed based on robot operating system frameworks, requiring developers to make intrusive modifications to the original robot function package source code to adapt to the MCP protocol, which increases development complexity.

[0025] Based on this, this specification proposes a service invocation scheme. By registering the target service, service description information is obtained. Server 102 publishes this service description information, and client 104 generates a service invocation request based on the service description information and sends it to server 102. Server 102 then converts the service invocation request into a service invocation message conforming to the message specification of the robot operating system based on conversion rules, and sends the service invocation message to the service node providing the target service on robot 106, thereby realizing the invocation of the target service. This method avoids intrusive modifications to the original robot function package source code, reducing development complexity. The specific implementation details of this scheme are illustrated below with reference to the accompanying drawings.

[0026] like Figure 2 The diagram illustrates a service invocation method applied to the server side, the method comprising:

[0027] Step S12: Receive a service call request from client 104 for the target service; the service call request is a request based on the model context protocol, and the service call request is generated based on the service description information pre-published by server 102. The service description information is obtained by registering the target service and is used to describe the generation rules of the service call request and the function of the target service.

[0028] Step S14: Obtain the conversion rules corresponding to the target service, and convert the service call request into a service call message that conforms to the message specification of the robot operating system based on the conversion rules. The conversion rules are used to define the conversion method of converting the service call request into a service call message.

[0029] Step S16: Send the service invocation message to at least one of the target service nodes that provides the target service to invoke the target service.

[0030] In step S12, the server 102 can pre-register the services provided by each service node. Specifically, in response to detecting that any service node has come online, the server 102 can register the services provided by that service node. In some embodiments, the server 102 can maintain a graph structure to record information about the online service nodes on the robot 106. The server 102 can determine whether there are any online or offline service nodes on the robot 106 based on this graph structure. For example, when the server 102 detects a newly added service node in the graph structure, it can determine that a service node has come online; when the server 102 detects that a service node has been deleted from the graph structure, it can determine that a service node has gone offline.

[0031] When registering a service node, the interface definition language of that service node can be obtained. The interface definition language corresponds to the service and can include the functions of the corresponding service and the parameter information involved in the service, such as the field names of the parameters, the data types of the parameters, and the default values.

[0032] In some embodiments, interface definition languages ​​can be maintained locally on both the server 102 and the robot 106. For example, after a service node in the robot 106 comes online, the service node can generate an interface definition language locally corresponding to the services it provides and synchronize a copy of that interface definition language to the server 102. If the interface definition language on the robot 106 changes, the service node can synchronize the change message to the server 102, allowing the server 102 to update its locally maintained interface definition language based on the change message. In this way, the interface definition languages ​​on the server 102 and the robot 106 can be kept synchronized.

[0033] In other embodiments, a synchronization interface can be created between server 102 and robot 106. Robot 106 can synchronize the interface definition language to server 102 through this synchronization interface. If the interface definition language on robot 106 changes locally, the service node can directly synchronize the changed interface definition language to server 102 through this synchronization interface. In the above method, the service node sends the dynamic interface definition language to server 102. Server 102 does not need to maintain a copy of the interface definition language, nor does it need to perform synchronization operations on the interface definition language, thus reducing system complexity.

[0034] After obtaining the interface definition language of the service node, server 102 can generate service description information conforming to the model context protocol based on the interface definition language and register the service description information. During registration, the service description information can be associated and mapped with the service's identification information (such as the service name), and registered as a tool conforming to the model context protocol.

[0035] Furthermore, when generating service description information, the interface definition language can be parsed to obtain the parameter information involved in the service. This parameter information is then converted into a specified format and parsed into service description information conforming to the model context protocol. The specified format recursively describes the parameter information involved in the service through object nesting. For example, the parameter information involved in the robot navigation service may include the three-dimensional coordinates x, y, z of robot 106 and the pitch, yaw, and roll angles of robot 106. This parameter information can be nested into a specified format according to logical relationships. For example, the three-dimensional coordinates x, y, z are assigned to the location object, the pitch, yaw, and roll angles are assigned to the attitude object, and the location and attitude are assigned to the pose object. The converted parameter information is as follows:

[0036]

[0037]

[0038] The service description information obtained through the above registration method can be used to describe the rules for generating service call requests and the functionality of the target service. The rules for generating service call requests can include parameter information related to the target service, which corresponds to the parameter information included in the interface definition language. The functionality of the target service included in the service description information corresponds to the functionality included in the interface definition language.

[0039] After registering the service description information, the registered service description information can be published to client 104. In some embodiments, server 102 can expose the registered service description information to client 104 through the "tools / list" method. The "tools / list" method is used to list all available tools. Server 102 can call this method to obtain a list of registered service description information and send the list to client 104 based on the model context protocol.

[0040] In some embodiments, server 102 may also unregister the service description information of the services provided by any service node upon detecting that the service node has gone offline. During unregistration, server 102 can delete the service description information of the services provided by the offline service node, at which point the client can no longer generate a call request for the services provided by the corresponding node based on the service description information.

[0041] Client 104 can generate a service invocation request based on the target service description information. This service invocation request can be a request based on the model context protocol, and it includes the parameter information described in the service description information.

[0042] In some embodiments, the service description information published by server 102 may include service description information corresponding to multiple services. Client 104 can generate prompt information based on the service description information published by server 102, and input the prompt information into large language model 108, so that large language model can determine the target service description information that matches the current task type from the service description information published by server 102. In some embodiments, the current task type can be determined based on user input information, and client 104 can generate prompt information based on user input information and service description information and input it into large language model 108. For example, assuming that server 102 publishes service description information corresponding to navigation service and service description information corresponding to perception service, and the current task type is robot path planning, then the target service description information that matches the current task type can be determined to be the service description information corresponding to navigation service.

[0043] Furthermore, the aforementioned prompts may also include contextual information. For example, in a multi-turn dialogue scenario, the contextual information may include historical dialogue information from the large language model 108. The prompts may also include information retrieved by the client 104 from data sources such as knowledge bases or the internet.

[0044] In step S14, the server 102 can obtain the conversion rules corresponding to the target service. These conversion rules define the conversion method for transforming a service call request into a service call message. Then, the server 102 can convert the service call request into a service call message that conforms to the message specification of the robot operating system based on the conversion rules.

[0045] In some embodiments, conversion rules are used to define the serialization method for service call requests. Server 102 can serialize service call messages based on the serialization method defined by the conversion rules. In some embodiments, the serialization method is the Common Data Representation (Object Management Group, CDR) serialization method. Server 102 can convert the service call message into a binary stream based on the CDR serialization method; this binary stream is the service call message conforming to the message specification of the robot operating system.

[0046] In step S16, server 102 can send a service call message to at least one target service node that provides the target service to invoke the target service. For example, server 102 can send the service call message to robot 106 through middleware (such as rmw middleware) of robot 106. Furthermore, if server 102 performs serialization processing on the service call message, the service call message sent by server 102 to robot 106 is a serialized message (such as the binary stream mentioned above).

[0047] In some embodiments, server 102 can also obtain the call result returned by the service node in response to the service call message, deserialize the call result, and return the deserialized call result to server 102. In some embodiments, client 104 and server 102 may include a message request interface and a message notification interface. Client 104 can send a service call request for the target service to server 102 through the message request interface, and server 102 can return the call result to client 104 through the message notification interface (such as the notify interface). In the above embodiments, server 102 can either passively communicate with client 104 in response to client 104's request and perform operations (such as generating a service call message in response to the client's service call request and sending the service call message to robot 106), or actively communicate with client 104, such as returning the call result of robot 106 to client 104. In the latter case, server 102 can return the call result without waiting for client 104's request, which is more efficient and can reduce the latency for client 104 to obtain the call result. In addition to returning the call result, the server 102 can also send other messages to the client 104 through the message notification interface, such as registration and unregistration messages for service description information.

[0048] The following is combined Figure 3An example of the overall process of an embodiment of this specification is provided. In this embodiment, the robot operating system is specifically the ROS2 system, and the model context protocol is the MCP protocol. For ease of description, the server 102 is referred to as the ROS2 MCP server, and the client 104 is referred to as the MCP client.

[0049] This specification proposes a "non-intrusive" method to quickly integrate the functions of robot 106 into large language model 108, thereby rapidly realizing a robot intelligent agent without requiring any intrusive modifications to the original robot function package source code, nor requiring additional secondary encapsulation or adaptation to the model context protocol.

[0050] This embodiment leverages ROS2's distributed nature and node discovery mechanism to detect the online and offline status of distributed ROS2 Actions, Services, and Topics (collectively referred to as ROS2 services) in real time. Specifically, when the ROS2 MCP server detects that a ROS2 service (including native ROS2 services and any user-defined ROS2 service) is online, it performs dynamic type mapping on the service. After successful mapping, the service is registered in the MCP client's toolset. When the ROS2 MCP server detects that a ROS2 service is offline, it deregisters the service from the MCP client's toolset. Ultimately, robot agent developers only need to deploy a single ROS2 MCP server at the near end to quickly invoke robot capabilities using LLM, significantly saving the effort and cost of building robot agents. Figure 3 As shown, the main process includes:

[0051] (1) When a ROS2 service node that provides ROS2 services (such as the " / robot / action / navi" service) comes online, the service will be detected by listening for the ROS2 Graph Event. Robot 106 can manage the service node based on rclcpp. rclcpp is a C++ client library for ROS2 that provides a standard C++ API for interacting with the ROS2 system. It is part of the standard ROS2 installation and is designed to provide developers with an efficient and flexible C++ interface to create and manage ROS2 nodes, publishers and subscribers.

[0052] (2) Through dynamic type parsing and reflection, a mapping relationship between "ROS2 service message definition" and "JSON schema" is obtained. The specific implementation method is as follows:

[0053] (i) Parse the ROS2 service's interface definition language into a "ROS2 service message definition", which contains details such as the field names, data types, and default values ​​of the ROS2 interface definition language;

[0054] (ii) Then the "ROS2 Service Message Definition" is parsed into a more general intermediate representation, which recursively describes each message field in the form of nested objects;

[0055] (iii) For the sake of functional scalability, this general intermediate representation is parsed into multiple schemas. In this embodiment, it is mainly parsed into a "JSON schema" (a JSON schema is a JSON object). This schema is the service description information in the aforementioned embodiment, which includes the "detailed functional description" and "message creation rules" of the ROS2 service. The "detailed functional description" is used to describe the functions of the ROS2 service, and the "message creation rules" are used to describe the generation rules of the service call request.

[0056] (iv) Map the “ROS2 service message definition” and “JSON schema” together using the “service name (i.e., the tool name of MCP)”.

[0057] (3) A tool that registers the “JSON schema” and “service name” together as an MCP.

[0058] (4) The ROS2 MCP server exposes all tools to the LLM through the "tools / list" method. In order to complete a given task, the LLM decides to call a tool provided by the MCP, and the LLM generates a service call request based on the JSON schema of the tool. The service call request is sent to the ROS2 MCP server through the "tools / call" method. This service call request includes parameters used to call the target service.

[0059] (5) After receiving the service call request, the ROS2 MCP server completes the tool invocation through the following process:

[0060] (i) Use the CDR serialization method, combined with the "ros2 service message definition" mentioned in step 2, to serialize the parameters in the service call request into a binary stream;

[0061] (ii) Use the binary stream to construct a ROS2 service call message and send the service call message to the corresponding ROS2 service node through the ROS2 middleware (rmw);

[0062] (iii) Provide the corresponding ROS2 service node to return the service call result (response) after receiving the service call message. The response is also a binary stream.

[0063] (iv) Using the CDR deserialization method, combined with the "ros2 service message definition" mentioned in step 2, deserialize the binary stream of the response into a "JSON object";

[0064] (v) The ROS2 MCP server returns the JSON object to the MCP client;

[0065] (vi) When a ROS2 service node containing a ROS2 service (such as the " / robot / action / manip" service) goes offline, the offline status of the service will be detected by listening to the ROS2 graph events. The MCP tool will be automatically unregistered. At this time, the MCP client can no longer call the MCP tool associated with the service.

[0066] See Figure 4 This specification also provides a service invocation method applied to a client 104 based on a model context protocol. The client 104 can communicate with a large language model 108 based on the model context protocol and communicate with a server 102. The server 102 also communicates with a robot 106 deployed with a robot operating system. The robot 106 includes at least one service node, which provides services based on the robot operating system. The method includes:

[0067] Step S22: Obtain the service description information pre-published by the server 102. The service description information is obtained by registering the target service and is used to describe the generation rules of the service call request and the function of the target service.

[0068] Step S24: Generate a service invocation request for the target service based on the service description information; the service invocation request is a request based on the model context protocol;

[0069] Step S26: Send the service call request to the server 102 so that the server 102 converts the service call request into a service call message that conforms to the message specification of the robot operating system based on the conversion rule corresponding to the target service, and sends the service call message to at least one target service node that provides the target service to call the target service; the conversion rule is used to define the conversion method of converting the service call request into a service call message.

[0070] In some embodiments, the method further includes: inputting service description information pre-published by the server 102 into the large language model 108, so that the large language model 108 determines target service description information that matches the current task type from the service description information pre-published by the server; and determining the service described by the target service description information as the target service.

[0071] For specific details of this embodiment, please refer to the aforementioned embodiment of the method executed by server 102, which will not be repeated here.

[0072] Figure 5 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 5 As shown, device 200 mainly consists of a communication interface 202, a user interface 204, a processor 206, and a data storage 208. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 210. The communication interface 202 enables device 200 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 202 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 202 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 202 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 202 may also include multiple physical communication interfaces, such as Wi-Fi interfaces, Bluetooth interfaces, and wide-area wireless interfaces.

[0073] User interface 204 includes receiving user input and providing output to the user. Therefore, user interface 204 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 204 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 204 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 200 may support remote access from other devices via communication interface 202 or another physical interface (not shown). User interface 204 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 204 may also be configured as a display device for rendering or displaying text fragments.

[0074] Processor 206 may include one or more general-purpose processors and / or special-purpose processors.

[0075] Data storage 208 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 206. Data storage 208 may include removable and non-removable components.

[0076] Processor 206 is capable of executing program instructions 218 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 208 to perform the various functions described herein. Data storage 208 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 200, enable device 200 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 206 executing program instructions 218 may result in processor 206 using data 212.

[0077] For example, program instructions 218 may include an operating system 222 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 200 and one or more applications 220 (e.g., a browser, social application, or game application). Similarly, data 212 may include operating system data 216 and application data 214. Operating system data 216 is primarily accessible to the operating system 222, while application data 214 is primarily accessible to one or more applications 220. Application data 214 may reside in a file system visible or hidden from the user of device 200.

[0078] Application 220 can communicate with operating system 222 through one or more application programming interfaces (APIs). These APIs help application 220 read and / or write application data 214, transmit or receive information via communication interface 202, receive or display information on user interface 204, etc.

[0079] In some terminology, application 220 may be simply referred to as "app". Furthermore, application 220 can be downloaded to device 200 through one or more online app stores or app markets. However, applications can also be installed on device 200 in other ways, such as through a web browser or a physical interface on device 200 (e.g., a USB port).

[0080] See Figure 6 This specification also provides a service invocation device applied to a server 102. The server 102 is communicatively connected to a robot 106 with a robot operating system and a client 104 based on a model context protocol. The robot 106 includes at least one service node, which provides services based on the robot operating system. The client 104 can communicate with a large language model 108 based on the model context protocol. The device includes:

[0081] The receiving module 302 is used to receive the service call request from the client for the target service; the service call request is a request based on the model context protocol, and the service call request is generated based on the service description information pre-published by the server. The service description information is obtained by registering the target service and is used to describe the generation rules of the service call request and the function of the target service.

[0082] The first acquisition module 304 is used to acquire the conversion rule corresponding to the target service, and convert the service call request into a service call message that conforms to the message specification of the robot operating system based on the conversion rule. The conversion rule is used to define the conversion method of converting the service call request into the service call message.

[0083] The first sending module 306 is used to send the service call message to the target service node that provides the target service among the at least one service node, so as to call the target service.

[0084] The aforementioned service invocation device can be applied to, for example... Figure 4 The device shown implements the technical solution described in this specification. Specific implementation details are detailed in the foregoing method embodiments and will not be repeated here.

[0085] See Figure 7 This specification also provides a service invocation device applied to a client 104 based on a model context protocol. The client 104 can communicate with a large language model 108 based on the model context protocol and communicate with a server 102. The server 102 is also communicated with a robot 106 deployed with a robot operating system. The robot 106 includes at least one service node, which is used to provide services based on the robot operating system. The device includes:

[0086] The second acquisition module 402 is used to acquire the service description information pre-published by the server. The service description information is obtained by registering the target service and is used to describe the generation rules of the service call request and the function of the target service.

[0087] The generation module 404 is used to generate a service invocation request for the target service based on the service description information; the service invocation request is a request based on the model context protocol.

[0088] The second sending module 406 is used to send the service call request to the server, so that the server converts the service call request into a service call message conforming to the message specification of the robot operating system based on the conversion rule corresponding to the target service, and sends the service call message to the target service node that provides the target service among the at least one service node to call the target service; the conversion rule is used to define the conversion method of converting the service call request into the service call message.

[0089] The aforementioned service invocation device can be applied to, for example... Figure 4 The device shown implements the technical solution described in this specification. Specific implementation details are detailed in the foregoing method embodiments and will not be repeated here.

[0090] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0091] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0092] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0093] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0094] What those skilled in the art will understand is:

[0095] In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0096] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0097] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0098] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0099] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0100] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0101] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A service calling method applied to a server, the server being communicatively connected with a robot deploying a robot operating system and a client based on a model context protocol, the robot comprising at least one service node for providing a service based on the robot operating system, and the client being capable of communicating with a large language model based on the model context protocol; the method comprising: receiving a service calling request of the client for a target service; the service calling request being a request based on the model context protocol, and the service calling request being generated based on service description information previously published by the server, the service description information being obtained by registering the target service and used for describing a generation rule of a service calling request and a function of the target service; obtaining a conversion rule corresponding to the target service, and converting the service calling request into a service calling message conforming to a message specification of the robot operating system based on the conversion rule, the conversion rule being used to define a conversion manner of converting the service calling request into the service calling message; sending the service calling message to a target service node of the at least one service node providing the target service, so as to call the target service.

2. The method of claim 1, further comprising: in response to listening to any one service node being online, obtaining an interface definition language of the service node; based on the interface definition language, generating service description information conforming to the model context protocol; registering the service description information, and publishing the registered service description information to the client.

3. The method of claim 2, wherein the generating of the service description information conforming to the model context protocol based on the interface definition language comprises: parsing the interface definition language to obtain parameter information related to the service; converting the parameter information into a specified format; the specified format recursively describing the parameter information related to the service in the form of object nesting; parsing the converted parameter information into service description information conforming to the model context protocol.

4. The method of claim 2, wherein the server maintains a graph structure, the graph structure being used to describe relationships between service nodes; the method further comprising: based on the graph structure, determining whether there is a service node being online.

5. The method of claim 2, further comprising: in response to listening to any one service node being offline, de-registering service description information of a service provided by the service node.

6. The method of claim 2, wherein the server and the service node comprise a synchronization interface, and the interface definition language is synchronized from the service node to the server through the synchronization interface.

7. The method of claim 1, wherein the conversion rule is used to define a serialization manner of the service calling request; and the converting of the service calling request into a service calling message conforming to a message specification of the robot operating system based on the conversion rule comprises: serializing the service call message based on a serialization manner defined by the conversion rule.

8. The method of claim 7, further comprising: obtaining a call result returned by the service node in response to the service call message; deserializing the call result; returning the deserialized call result to the service end.

9. The method of claim 1, wherein the client and the service end comprise a message request interface and a message notification interface; the receiving the service call request for the target service from the client comprises receiving the service call request for the target service sent by the client through the message request interface; the method further comprises obtaining a call result returned by the service node in response to the service call message, and returning the call result to the client through the message notification interface.

10. The method of claim 1, wherein the service end comprises a user interface; the method further comprises: in response to receiving a modification instruction sent through the user interface, modifying the description information.

11. A service call method applied to a client based on a model context protocol, the client being capable of communicating with a large language model based on the model context protocol, and being in communication connection with a service end, the service end also being in communication connection with a robot deployed with a robot operating system, the robot comprising at least one service node for providing a service based on the robot operating system; the method comprising: obtaining service description information pre-published by the service end, the service description information being obtained by registering a target service, and being used to describe a generation rule of a service call request and a function of the target service; generating a service call request for the target service based on the service description information; the service call request being a request based on the model context protocol; sending the service call request to the service end, so that the service end converts the service call request into a service call message conforming to a message specification of the robot operating system based on a conversion rule corresponding to the target service, and sends the service call message to a target service node providing the target service among the at least one service node, to call the target service; the conversion rule being used to define a conversion manner of converting the service call request into the service call message.

12. The method of claim 11, further comprising: inputting the service description information pre-published by the service end into the large language model, so that the large language model determines target service description information matching a current task type from the service description information pre-published by the service end; determining a service described by the target service description information as a target service.

13. An electronic device comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the method of any one of claims 1-12 by running the executable instructions.

14. A computer readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method of any one of claims 1-12.

15. A computer program product comprising computer programs / instructions that, when executed by a processor, implement the steps of the method of any one of claims 1-12.

Images