Methods, apparatus, devices, and storage media for generating message conversion plugins

Abstract

This disclosure provides a method, apparatus, device, and storage medium for generating message conversion plugins, relating to the field of computer technology, particularly artificial intelligence, autonomous driving, and software development. The specific implementation involves: obtaining the basic file of the message conversion plugin, which is used to generate the plugin in a bridging middleware; wherein the message conversion plugin is used to perform message conversion between a first frame and a second frame; compiling the basic file of the message conversion plugin, and generating the plugin in the bridging middleware. According to this disclosure, message pathways between different frames can be established, enabling flexible message conversion.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to artificial intelligence, autonomous driving, and software development. Background Technology

[0002] The Robot Operating System (ROS) is a general-purpose robot operating system framework that provides a series of tools, libraries, and communication mechanisms for the development of various robots, enabling developers to efficiently build complex robot applications. ROS has a wide range of applications, including industrial robots, service robots, and autonomous driving-related research and testing. Autonomous driving software platforms and ROS can establish connections and exchange data through network communication protocols. However, the message definitions of some autonomous driving software platforms differ from those of ROS messages, making message conversion between them difficult. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, and storage medium for generating a message conversion plugin.

[0004] According to one aspect of this disclosure, a method for generating a message conversion plugin is provided, comprising:

[0005] Obtain the basic files of the message conversion plugin, which are used to generate the message conversion plugin in the bridging middleware; wherein, the message conversion plugin is used to perform message conversion between the first frame and the second frame;

[0006] Compile the basic files of the message conversion plugin and generate the message conversion plugin in the bridging middleware.

[0007] According to another aspect of this disclosure, a message conversion method is provided, comprising:

[0008] Receive the message to be converted from the first frame or the second frame through the bridging middleware;

[0009] The bridging middleware invokes the corresponding message conversion plugin to perform message conversion between the first and second frames based on the message to be converted.

[0010] According to another aspect of this disclosure, an apparatus for generating a message conversion plugin is provided, comprising:

[0011] The message conversion plugin acquisition module is used to acquire the basic file of the message conversion plugin, which is used to generate the message conversion plugin in the bridging middleware; wherein, the message conversion plugin is used to perform message conversion between the first frame and the second frame;

[0012] The message conversion plugin compilation module is used to compile the basic files of the message conversion plugin and generate the message conversion plugin in the bridging middleware.

[0013] According to another aspect of this disclosure, a message conversion apparatus is provided, comprising:

[0014] The receiving module is used to receive messages to be converted from the first frame or the second frame through the bridging middleware;

[0015] The calling module is used to invoke the corresponding message conversion plugin to perform message conversion between the first frame and the second frame based on the message to be converted through the bridging middleware.

[0016] According to another aspect of this disclosure, an electronic device is provided, comprising:

[0017] At least one processor; and

[0018] The memory is communicatively connected to the at least one processor; wherein,

[0019] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0020] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0021] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0022] According to this disclosure, a bridging middleware is generated between the first and second frames, and a message conversion plugin is generated in the bridging middleware, which can open up message channels between different frames and flexibly perform message conversion.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0024] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0025] Figure 1 This is a flowchart illustrating a method for generating a message conversion plugin according to an embodiment of the present disclosure;

[0026] Figure 2 This is a flowchart illustrating a method for generating a message conversion plugin according to another embodiment of the present disclosure;

[0027] Figure 3 This is a flowchart illustrating a method for generating a message conversion plugin according to another embodiment of the present disclosure;

[0028] Figure 4 This is a flowchart illustrating a method for generating a message conversion plugin according to another embodiment of the present disclosure;

[0029] Figure 5 This is a flowchart illustrating a method for generating a message conversion plugin according to another embodiment of the present disclosure;

[0030] Figure 6 This is a flowchart illustrating a method for generating a message conversion plugin according to another embodiment of the present disclosure;

[0031] Figure 7 This is a flowchart illustrating a message conversion method according to an embodiment of the present disclosure;

[0032] Figure 8 This is a flowchart illustrating a message conversion method according to another embodiment of the present disclosure;

[0033] Figure 9 This is a flowchart illustrating a message conversion method according to another embodiment of the present disclosure;

[0034] Figure 10 An example diagram of a flexible message transformation framework;

[0035] Figure 11 This is a schematic diagram of the structure of a message conversion plugin generation device according to an embodiment of the present disclosure;

[0036] Figure 12 This is a schematic diagram of the structure of a message conversion plugin generation apparatus according to another embodiment of the present disclosure;

[0037] Figure 13 This is a schematic diagram of the structure of a message conversion device according to an embodiment of the present disclosure;

[0038] Figure 14 This is a schematic diagram of the structure of a message conversion device according to another embodiment of the present disclosure;

[0039] Figure 15 This is a block diagram of an electronic device used to implement embodiments of the present disclosure. Detailed Implementation

[0040] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0041] Figure 1 This is a flowchart illustrating a method 100 for generating a message conversion plugin according to an embodiment of the present disclosure. The method includes:

[0042] S110. Obtain the basic file of the message conversion plugin, which is used to generate the message conversion plugin in the bridging middleware; wherein, the message conversion plugin is used to perform message conversion between the first frame and the second frame;

[0043] S120. Compile the basic files of the message conversion plugin and generate the message conversion plugin in the bridging middleware.

[0044] In this embodiment, the framework may include a software development framework that provides a series of tools, libraries, etc., to help developers build complex applications more efficiently. For example, the first framework may be a Robot Operating System (ROS). ROS can be used to write robot software programs; it can be built on top of traditional operating systems such as Linux, providing communication mechanisms, hardware abstraction, software reuse, and other functions for robot development. As another example, the second framework may be a framework within an autonomous driving platform, such as a real-time runtime framework within the autonomous driving platform, which can be used to efficiently handle various tasks in the autonomous driving system.

[0045] In this embodiment, the message definitions of different frames are usually different, and message conversion is required when passing messages between different frames. The basic files of a message conversion plugin may include header files, source files, etc. The basic files of different types of message conversion plugins may be different. Based on the basic files of a certain type of message conversion plugin, this type of message conversion plugin can be generated in the bridging middleware. Each message conversion plugin can be used to convert a type of message between the first frame and the second frame. For example, a radar message conversion plugin can convert radar messages between the first frame and the second frame, a positioning message conversion plugin can convert positioning messages between the first frame and the second frame, and a navigation message conversion plugin can convert navigation messages between the first frame and the second frame.

[0046] The message conversion plugin can be generated by sending the basic files of the message conversion plugin to the compilation system in the operating system for compilation.

[0047] By generating bridging middleware and message conversion plugins between the first and second frames, message pathways between different frames can be established, enabling flexible message conversion.

[0048] In one implementation, the message conversion plugin is used to convert a first message from the first frame into a second message from the second frame, and / or to convert a second message from the second frame into a first message from the first frame.

[0049] In this embodiment, the message conversion plugin can convert a first message from the first frame into a second message that the second frame can process, according to the first conversion logic of the plugin, and then send it to the second frame. Conversely, the message conversion plugin can convert a second message from the second frame into a first message that the first frame can process, according to the second conversion logic of the plugin, and then send it to the first frame. The first and second conversion logics can be related, for example, they can be opposite conversion logics. The message conversion plugin allows for flexible message conversion between the first and second frames.

[0050] For example, a first-level framework like ROS can include nodes and packages. A node can be understood as the basic unit of execution in ROS; each node can perform a specific function, such as image processing, localization, or radar. Nodes communicate with each other through topics and services. Topics can be used to transmit continuous data streams. For example, radar data, image data, and localization data can be published in the form of topics. Services can be understood as communication mechanisms that support request / response interaction patterns. A package can be understood as a way of organizing software in ROS; it can contain nodes, configuration files, message definitions, etc. For example, a ROS package can contain all the code and resources that implement a specific function. Messages are the data format for topic communication. The format of a message can be a combination of simple data types (such as integers, floating-point numbers, etc.) or a custom structure.

[0051] The second framework can include components, which are the basic units for task execution. Messages are the basic carriers for communication between components. They are data structures that can be defined for transmission between different parts of the system, used to carry information that the sender wants to pass to the receiver. This information can be various data types such as sensor data, control commands, and status reports. The format of a message can be a combination of simple basic data types (such as integers, floating-point numbers, and Boolean values) or a custom structure.

[0052] Figure 2This is a flowchart illustrating a method 200 for generating a message conversion plugin according to another embodiment of the present disclosure. Method 200 can be used to implement method 100 for generating a message conversion plugin. In one embodiment, method 200 further includes:

[0053] S210. Obtain the basic file of the first frame, which is used to generate the bridging middleware between the first frame and the second frame;

[0054] S220. Compile the basic files of the first framework to generate the bridging middleware.

[0055] In this embodiment of the disclosure, after installing the first framework in a conventional operating system, the basic files of the first framework can be obtained. The basic files of the first framework may include tools, dynamic libraries, header files, etc. The basic files of the first framework may differ in different distributions. Bridging middleware can be generated based on the basic files of the first framework.

[0056] In one embodiment, method 200 further includes S230 and S240, wherein S230 may refer to S110 in method 100, and S240 may refer to S120 in method 100.

[0057] The basic files for the first frame and the message conversion plugin can be sent to the compilation system together for compilation, or they can be compiled separately. The choice depends on the specific application scenario. The bridging middleware allows each message conversion plugin to flexibly perform message conversion between the first and second frames.

[0058] Figure 3 This is a flowchart illustrating a method 300 for generating a message conversion plugin according to another embodiment of the present disclosure. In one embodiment, the method 300 for generating a message conversion plugin further includes:

[0059] S310. Check if the first frame is already installed in the target path;

[0060] S320. If the first framework is already installed in the target path, obtain the release information of the first framework. The release information of the first framework is used to obtain the basic files of the first framework.

[0061] In this embodiment, the system first checks if a first framework is installed in the target path of the operating system. For example, it searches for ROS installed in the / opt / ros path. If it is installed, it indicates that the first framework is installed in the operating system; otherwise, it indicates that the first framework is not installed. If the first framework is installed in the operating system, its distribution information can be obtained first. A framework may have multiple distributions (or versions). For example, ROS has distributions such as ROS1 and ROS2. ROS2 also includes versions such as ROS2Foxy Fitzroy and ROS2Galactic Geochelone. If ROS is installed, the ROS distribution information is obtained, and a header file containing the distribution information is generated. Then, based on the first framework's distribution information, the basic files of the first framework are collected and compiled using the compilation system in the operating system to generate the bridging middleware. Compiling the bridging middleware based on the basic files of the first framework allows it to inherit existing information from the first framework, simplifying the generation process of the bridging middleware.

[0062] In one implementation, the message conversion plugin generation method 300 further includes:

[0063] S330. If the first framework is not installed in the target path, generate an empty header file. This empty header file is used to disable the first framework when compiling the bridging middleware.

[0064] In this embodiment, if the first framework is not installed in the target path, i.e., the operating system does not have the first framework installed, the existing information of the first framework cannot be inherited to generate the bridging middleware. Instead, an empty header file is used to flexibly compile and generate a bridging middleware that does not enable the first framework. An empty header file can also be compiled into bridging middleware because without ROS, the executable file of the bridging middleware does not need to communicate with ROS. For example, if a C++ compilation mechanism is used, if the source code of the bridging middleware includes this header file, an empty file can be generated even if the header file contains no content. In this way, the compiler will not fail to compile due to not finding this file.

[0065] In one implementation, method 300 further includes:

[0066] S340. Generate a header file containing the release information, which is used to enable the compiled bridging middleware to adapt to the communication interface of different versions of the first framework.

[0067] In this embodiment of the disclosure, if ROS is already installed, the ROS distribution information is obtained, and a header file containing the distribution information is generated. For example, a header file including ROS2Foxy Fitzroy is generated.

[0068] In this embodiment, a header file containing distribution information of the first framework can be passed to the compilation system via macros. A macro is a preprocessor directive used for code transformation and generation during the compilation phase. Macros can be defined to identify different ROS distributions, and the installed ROS distribution information can be passed to the compilation system via macros. The compilation system can then set different compilation options based on the defined macros containing distribution information and select the appropriate RCLCPP (ROSClient Library for C++, a C++ library in ROS) interface calling method. The RCLCPP interfaces of different distributions may differ in many aspects, such as parameter settings, function calling methods, and supported features, and accurate interface calls can be made based on macros containing distribution information.

[0069] Figure 4 This is a flowchart illustrating a method 400 for generating a message conversion plugin according to another embodiment of the present disclosure. Method 400 can be used to implement step S110 in method 100 for generating a message conversion plugin. In one embodiment, method 400 includes: obtaining the basic files of the first framework, and further includes:

[0070] S410. Based on the release information of the first framework, collect the header files and dynamic libraries of the first framework;

[0071] S420. Based on the header file and the dynamic library, use the set template to generate the rule library corresponding to the first framework. The rule library is used to compile and generate the bridging middleware.

[0072] In this embodiment, the header files of the first framework can contain necessary type definitions, function declarations, and macro definitions. For example, ROS header files can tell the compiler how to correctly compile code involving ROS functionality. ROS header files come in various types, including core functionality-related header files (such as ros / ros.h), message type-related header files (such as std_msgs / String.h), etc. These header files can contain definitions related to ROS nodes, messages, services, etc., facilitating the creation and use of these functions. The dynamic libraries of the first framework can be used to support various functions. For example, ROS dynamic libraries can include core dynamic libraries, message processing dynamic libraries, and visualization-related dynamic libraries. Core dynamic libraries such as libroscpp.so and librcl.so can provide functions for message publishing and subscription, and can also support service invocation and provision. Message processing dynamic libraries such as libmessage_filters.so can implement message filtering and synchronization functions.

[0073] In this embodiment, the rule base configuration template may include a name, file path, library visibility, etc. For example, the rule base cc_library specifies the library name, source files (.cc files), header files (.h files), dependencies, and other information. cc_library is compiled using a build system to generate bridging middleware. The aforementioned header files including distribution information, collected ROS header files, dynamic libraries, etc., can be sent to the build system for compilation to generate bridging middleware.

[0074] The bridge middleware generated by compiling the rule base using the header files and dynamic libraries of the first framework can inherit the existing information of the first framework, simplifying the generation process of the bridge middleware.

[0075] Figure 5 This is a flowchart illustrating a method 500 for generating a message conversion plugin according to another embodiment of the present disclosure. Method 500 can be used to implement step S110 in method 200 for generating a message conversion plugin. In one embodiment, method 500 includes: obtaining basic files for the message conversion plugin, and further includes:

[0076] S510. Include the header file for this message conversion plugin;

[0077] S520. In the header file of this message conversion plugin, inherit the message conversion base class;

[0078] S530. Define a conversion function in the header file of the message conversion plugin; wherein the message conversion logic of the conversion function is in the source file of the message conversion plugin.

[0079] S540. Register the message conversion plugin. For example, use the macros provided by the second framework to register the message conversion plugin.

[0080] In this embodiment of the disclosure, a certain type of message conversion plugin may have a corresponding header file. For example, the header file of a radar message conversion plugin may include linda_pointcloud.h. This header file can be used to declare functions, classes, structures, and define related constants related to point cloud data processing. This header file provides necessary interface information for other source files, enabling these source files to correctly call and use functions related to point cloud processing. In the header file of the message conversion plugin, a message conversion base class can be inherited, and conversion functions can be defined. A conversion function can be used to represent a type of message conversion logic. For example, a radar message conversion function can be used to define radar message conversion logic. A navigation message conversion function can be used to define navigation message conversion logic.

[0081] In this embodiment of the disclosure, the macros in the second framework can perform code transformation and generation during the compilation stage. A message transformation plugin is registered using macros in the second framework for registering plugins.

[0082] By inheriting the message conversion base class from the header file and defining conversion functions, the message communication interface of the message conversion plugin can be quickly generated, flexibly supporting various message conversion functions. This decouples the message communication interface from the message conversion logic, reduces the development difficulty of the message conversion plugin, and thus improves development efficiency.

[0083] In one implementation, the basic files of the message conversion plugin include one or more of the following: a compilation description file, a configuration file, a plugin description file, a header file, and a source file;

[0084] The compilation description file is used to describe the source code and / or compilation method of the message conversion plugin;

[0085] This configuration file contains information about the input and / or output channels of the message conversion plugin;

[0086] This plugin description file describes the dynamic libraries that this message conversion plugin needs to load.

[0087] In one implementation, the header file of the message conversion plugin includes one or more of the following: the base class that the message conversion plugin inherits from, the types of the input messages and / or output messages of the message conversion plugin, and the function definitions of the message conversion plugin.

[0088] In one implementation, the source file of the message conversion plugin includes the message conversion logic.

[0089] In this embodiment, a message conversion plugin can be generated by compiling a description file, a configuration file, a plugin description file, a header file, and a source file. For example, the description file is named BUILD bazel; the configuration file is named conf; the plugin description file can also be called a plugin implementation file, such as plugins.xml; the header file of a message conversion plugin is lidar_pointcloud.h, which defines which base class the plugin inherits from, the types of input and output messages, and the necessary function definitions; the source file of a message conversion plugin is lidar_pointcloud.cc, which implements the radar message conversion logic. The conversion functions in the source file can be used to define the message conversion logic, such as the type, format, and steps of message conversion.

[0090] By inheriting the message conversion base class from the header file, the message communication interface of the message conversion plugin can be quickly generated. The message conversion function can be flexibly set through the message conversion logic in the source file. The message communication interface and the message conversion logic can be decoupled, reducing the development difficulty of the message conversion plugin and thus improving development efficiency.

[0091] Figure 6 This is a flowchart illustrating a method 600 for generating a message conversion plugin according to another embodiment of this disclosure. Method 600 can be used to implement step S220 in method 100 for generating a message conversion plugin. In one embodiment, method 600 includes: compiling the basic files of the first framework to generate a bridging middleware, and further includes:

[0092] S610. Using the header file, dynamic library, and rule base corresponding to the first framework, compile to generate the executable file of the bridging middleware. The executable file of the bridging middleware includes message conversion base classes corresponding to the basic units of the first and second frameworks. The message conversion base classes are used to support the message communication interface of the message conversion plugin.

[0093] In one embodiment, method 600 can be used to implement step S120 (or step S240 in method 200) in method 100 for generating a message conversion plugin. In one embodiment, method 600 includes: compiling the basic files of the message conversion plugin to generate the message conversion plugin, and further includes:

[0094] S620. Based on the basic files of the message conversion plugin, compile and generate the dynamic library of the message conversion plugin. The dynamic library of the message conversion plugin is used to inherit the message conversion base class of the message conversion plugin and support the message conversion logic of the message conversion plugin.

[0095] In this embodiment, in both the first and second frames, the message transformation base class can be used to define general interfaces and behaviors for message transformation, so that different types of message transformation operations can inherit from this base class and implement their own specific transformation logic. The basic unit of the first frame can include a node, such as a ROS node, while the basic unit of the second frame can include a component. The base class can include common interfaces and functions within the framework. For example, the ROS base class can include base classes related to ROS nodes. The ROS base class can more efficiently create various ROS nodes, message processing components, etc. These base classes encapsulate some underlying ROS mechanisms, such as node initialization and message communication. Furthermore, the base class can include component-related base classes. In the second frame, a component is a module with specific functions, such as a sensor data processing component, a decision-making component, or an execution component. Component-related base classes can include basic interfaces that provide lifecycle management for components and communication with other components.

[0096] In this embodiment, the bridging middleware and the message conversion plugin can be compiled together after all the basic files of the first framework and the message conversion plugin are obtained. For example, the header files, dynamic libraries, and rule bases of the first framework can be sent to the compilation system and compiled together with the compilation description files, header files, dynamic libraries, and other basic files of the second framework to generate the bridging middleware. The basic files of the second framework can be predefined. The compiled bridging middleware can include a message conversion base class, which can implement the message communication interface of the message conversion plugin. Alternatively, after obtaining the basic files of the first framework, S610 can be executed first to compile the bridging middleware, and after obtaining the basic files of the message conversion plugin, S620 can be executed to compile the message conversion plugin.

[0097] In this embodiment, the message conversion base class can define the message communication interface of the message conversion plugin. This interface can specify the communication mechanism for sending and / or receiving messages. Based on the basic files of the message conversion plugin, a dynamic library for the plugin can be compiled.

[0098] In this embodiment, the message conversion base class can support many-to-many message conversion, such as 4-to-4 message conversion. One ROS message can be converted into messages from multiple autonomous driving platforms. Conversely, one message from an autonomous driving platform can be converted into multiple ROS messages.

[0099] By inheriting the message conversion base class, the message communication interface and message conversion logic can be decoupled. Only the message conversion logic needs to be developed, which can reduce the development difficulty of message conversion plugins and improve development efficiency.

[0100] Figure 7This is a flowchart illustrating a message conversion method 700 according to an embodiment of the present disclosure, the method comprising:

[0101] S710: Receive the message to be converted from the first frame or the second frame through the bridging middleware;

[0102] S720: Based on the message to be converted, the bridging middleware calls the corresponding message conversion plugin to perform message conversion between the first and second frames.

[0103] In one scenario, the bridging middleware can receive messages to be converted from the first frame, then invoke the message conversion logic of the corresponding message conversion plugin to convert the message into a message that the second frame can process, and then send it to the second frame. For example, if the bridging middleware receives a radar message from the first frame, it can invoke the radar message conversion plugin to convert the radar message into a message that the second frame can process. Similarly, if the bridging middleware receives a GNSS message from the first frame, it can invoke the GNSS message conversion plugin to convert the GNSS message into a message that the second frame can process. In another scenario, the bridging middleware can receive messages to be converted from the second frame, then invoke the message conversion logic of the corresponding message conversion plugin to convert the message into a message that the first frame can process, and then send it to the first frame. For example, if the bridging middleware receives a perception message from the second frame, it can invoke the perception message conversion plugin to convert the perception message into a message that the first frame can process.

[0104] By using a bridging middleware to call a message conversion plugin to convert messages from different frameworks, message pathways between different frameworks can be established, allowing for flexible message conversion.

[0105] Figure 8 This is a flowchart illustrating a message conversion method 800 according to another embodiment of the present disclosure. Method 800 can be used to implement step S710 in message conversion method 700. In one embodiment, method 800 includes: receiving a message to be converted from a first frame or a second frame via a bridging middleware, further including:

[0106] S810. Create the subscription client for the first frame through this bridging middleware;

[0107] S820, Receive the first message from the first frame through the subscriber.

[0108] In this embodiment of the disclosure, the bridging middleware can create a receiver, such as a subscriber, for a first frame. The receiver of the first frame can be understood as a component of the bridging middleware. Through this subscriber, a first message from the first frame can be received, and the message conversion plugin corresponding to the first message can be invoked to convert the first message into a second message that the second frame can process. The subscriber for the first frame created by the bridging middleware facilitates the reception and conversion of messages from the first frame to the second frame.

[0109] In one embodiment, method 800 can be used to implement step S720 in message conversion method 700. In one embodiment, method 800 includes: using the bridging middleware to call a corresponding message conversion plugin to perform message conversion between a first frame and a second frame based on the message to be converted, further including:

[0110] S830. The subscription client calls the message conversion plugin corresponding to the topic information of the first message to convert the first message into a second message.

[0111] S840, Create the write end of the first frame through this bridging middleware;

[0112] S850, The second message is sent to the second frame through the writing end.

[0113] In this embodiment, the subscriber of the first frame created by the bridging middleware can not only receive the first message from the first frame, but also call the message transformation logic of the message transformation plugin, such as a transformation function, through a topic callback function to transform the first message into a second message that the second frame can process. Furthermore, the bridging middleware can create a sender, such as a writer, for the first frame, through which the second message can be sent to the second frame. The sender of the first frame can be understood as a component of the bridging middleware. The writer of the first frame created by the bridging middleware facilitates sending the transformed message to the second frame.

[0114] In one example, the message translation process from ROS to the autonomous driving platform may include:

[0115] (1) The bridging middleware can create a ROS subscription through code. The subscription code can include the topic information (ros_topic_name) of the ROS message. The subscription code can also include a topic callback function (TopicCallback), which is the callback function for receiving ROS messages. This callback function can call the transformation function of the message transformation plugin corresponding to the topic information of the ROS message to transform the ROS message and output the message of the autonomous driving platform.

[0116] (2) The bridging middleware can create a writer for the autonomous driving platform through code and call the writer to send the transformed messages from the autonomous driving platform to the autonomous driving platform. For example, the writer can obtain the channel information (set_channel_name) of the second frame, and also obtain the topic information (ros_topic_name) of the first frame. Through topic callback functions (TopicCallback), shared pointers (shared_ptr), input containers (in_container), output containers (out_container), etc., the transformed messages from the second frame of the autonomous driving platform are sent to the second frame of the autonomous driving platform.

[0117] Figure 9 This is a flowchart illustrating a message conversion method 900 according to another embodiment of the present disclosure. Method 900 can be used to implement step S710 in message conversion method 700. In one embodiment, method 900 includes: receiving a message to be converted from a first frame or a second frame through a bridging middleware, further including:

[0118] S910. Create the reading end of the second frame through the bridging middleware;

[0119] S920, Receive a second message from the second frame through the reading end.

[0120] In this embodiment of the disclosure, the bridging middleware can create a receiving end, such as a reading end, for the second frame. The receiving end of the second frame can be understood as a component of the bridging middleware. Through this reading end, a second message from the second frame can be received, and the message conversion plugin corresponding to the second message can be invoked to convert the second message into a first message that the first frame can process. The reading end of the second frame created by the bridging middleware facilitates the reception and conversion of messages from the second frame to the first frame.

[0121] In one embodiment, method 900 can be used to implement step S720 in message conversion method 700. In one embodiment, method 900 includes: using the bridging middleware to call a corresponding message conversion plugin to perform message conversion between a first frame and a second frame based on the message to be converted, further including:

[0122] S930. The message conversion plugin corresponding to the channel information of the second message is called through the reading end to convert the second message into the first message;

[0123] S940. Create the publishing end of the first frame through this bridging middleware;

[0124] S950, The first message is sent to the first frame through the publishing end.

[0125] In this embodiment, the reading end of the second frame created by the bridging middleware can not only receive the second message from the second frame, but also call the message conversion logic of the message conversion plugin, such as a conversion function, through a callback function (func), to convert the second message into a first message that the first frame can process. Furthermore, the bridging middleware can create a sending end, such as a publishing end, for the second frame, through which the first message can be sent to the first frame. The sending end of the second frame can be understood as a component of the bridging middleware. The publishing end of the second frame created by the bridging middleware facilitates sending the converted message to the first frame.

[0126] In one example, the message translation process from an autonomous driving platform to ROS may include:

[0127] (1) The bridging middleware can create a reader for the autonomous driving platform through code. The reader's code can include the channel information (reader_cfg) of the ROS message. The reader's code can also include a callback function (func), which is the callback function that receives the message from the autonomous driving platform's framework. This callback function can call the conversion function of the message conversion plugin corresponding to the channel information of the message to convert the message and output the ROS message.

[0128] (2) The bridging middleware can create a ROS publisher through code and call the publisher to send the converted ROS messages from the autonomous driving platform's framework to ROS. For example, the publisher can obtain the topic information (ros_topic_name) of the first framework. It can then send the converted ROS messages to ROS through callback functions (func), shared pointers (shared_ptr), input containers (in_container), and output containers (out_container).

[0129] In one application scenario, the message definitions of the autonomous driving platform and ROS messages differ, requiring the ROS bridge to support message conversion logic between them. However, the message conversion code of the ROS bridge is tightly coupled with the communication interface of the autonomous driving platform framework and the ROS RCLCPP interface, resulting in high learning costs, low usability, and difficulty in maintenance. Implementing a single message conversion requires writing a complete set of ROS nodes and components of the autonomous driving platform framework, leading to a large amount of redundant code and additional code management costs.

[0130] This embodiment of the disclosure decouples the message conversion logic from the internal operating logic of ROS_bridge based on the plug-in mechanism of the autonomous driving platform framework. ROS uses the RCLCPP communication interface, while the autonomous driving platform framework itself also has a set of communication interfaces. Due to the huge differences between the underlying version and application layer interface of the message middleware, the two are incompatible and the migration and adaptation costs are high.

[0131] This disclosure proposes a flexible message conversion framework based on the plug-in mechanism of an autonomous driving platform framework. Users only need to focus on the message conversion logic and develop message conversion plug-ins, without needing to worry about the processing of various communication interfaces. An example of such a message conversion framework is as follows: Figure 10 As shown:

[0132] I. A message transformation framework may include the following components:

[0133] 1. Autonomous driving platform business modules: These are the conventional modules in the autonomous driving platform, such as path planning and control (PNC), prediction and perception, etc.

[0134] 2. Framework of the autonomous driving platform: Communication interface of the autonomous driving platform.

[0135] 3. ROS bridge: A pluggable message transformation framework responsible for message transformation.

[0136] 4. ROS Environment Auto-Configuration Rule (bazel ros env auto-configured rule): Based on custom rules from open-source build and testing tools, this rule automatically identifies which version of ROS is installed in the environment. When compiling the ROS bridge, it passes the corresponding ROS version information via macros. The compilation uses code compatible with the current ROS version, ensuring that the code can compile and run correctly in environments with different ROS versions.

[0137] 5. RCLCPP: ROS communication interface. Due to the large number of ROS versions, different versions of the communication interface exist, and the definition of their Application Programming Interface (API) will also differ. For example, RCLCPP IRON, RCLCPP FOXy, etc.

[0138] 6. ROS software packages: These are the standard ROS software packages, such as lidar drivers, Global Navigation Satellite System (GNSS) drivers, and Simultaneous Localization and Mapping (SLAM) positioning.

[0139] II. The ROS bridge mainly includes the following functions:

[0140] 1. Configuration rule (bazel ros env auto configured rule): Used to confirm the current ROS environment, collect ROS-related header files and dynamic libraries, and pass ROS version information for use during compilation to adapt to the communication interface of different versions of ROS rclcpp.

[0141] The main process example is as follows:

[0142] (1) Based on the repository rule (bazel repository_rule), execute the shell command to search for whether ROS is installed in the / opt / ros path. If not, generate an empty header file. ROS communication is not enabled during the compilation of ROS_bridge.

[0143] (2) If ROS is already installed, a header file with distribution information will be generated. An example code is shown below:

[0144] #define ROS_DISTRO_IRON 1

[0145] ROS distribution information is passed via macros to use the correct RCLCPP interface.

[0146] (3) Collect ROS header files and dynamic libraries through generation rules, and generate corresponding cc_library according to the template for use when compiling ROS_bridge.

[0147] 2. Message Transformation Base Class: Used to decouple the communication interface from the message transformation logic. The base class contains ROS nodes and components of the autonomous driving platform framework, and implements many-to-many message transformation, such as supporting 4-to-4 message transformation.

[0148] The role of the base class is to decouple the message communication interface from the message conversion logic, so that developers only need to focus on message conversion, without having to worry about how the message is transmitted.

[0149] Taking lidar-driven message conversion as an example, the following is an example of the files needed to implement a message conversion plugin:

[0150] BUILD is a compilation description file that describes how to compile the corresponding source code.

[0151] Conf is the configuration file for the message conversion plugin, which typically contains information such as input channels and output channels.

[0152] plugins.xml is a plugin description file that specifies information such as the dynamic libraries that the plugin needs to load.

[0153] lidar_pointcloud.h is the header file for the message conversion plugin. It defines which base class the plugin inherits from, the types of messages for input and output, and the necessary function definitions.

[0154] lidar_pointcloud.cc is the source file for the message conversion plugin, which implements the message conversion logic.

[0155] The following is an example of the implementation of the header file lidar_pointcloud.h:

[0156] (1) Include the necessary header files, such as the necessary header files for the framework of the autonomous driving platform;

[0157] Include the header file for the corresponding ROS message (i.e., ROS message), for example, sensor_msgs / point_cloud2_iterator.hpp;

[0158] Define the input and output of the message, such as InputMsg and OutputMsg.

[0159] (2) Inherit the base class and define conversion functions.

[0160] In the header file, by inheriting the base class, it is possible to support one-to-one message conversion plugins, one-to-many message conversion plugins, many-to-one message conversion plugins, and many-to-many message conversion plugins.

[0161] For example, ROS**MessageConverter <InputTypes <inputmsgptr>,0utputTypes<0utputMsgPtr>> can represent a one-to-one message conversion plugin, which can convert a message in ROS into a message in the framework of an autonomous driving platform.

[0162] For example, ROS MessageConverter <InputTypes<InputMsgPtr1,InputMsaPtr2> 0utputTypes<0utputMsgPtr>> can represent a 2-to-1 message conversion plugin, which can convert 2 messages in ROS into 1 message in the framework of an autonomous driving platform.

[0163] For example, **ROSMessageConverter** <InputTypes<InputMsgPtr1,InputMsaPtr2> 0utputTypes<0utputMsgPtr>> can represent a 2-to-1 message conversion plugin, which can convert 2 messages in the framework of an autonomous driving platform into 1 message in ROS.

[0164] In some examples, the autonomous driving platform can support 4-to-4 message conversion plugins.

[0165] In the header file, you can define conversion functions, which can support message conversion logic. For example, a conversion function ConvertMsg can include the message's input type (InputTypes), output type (OutputTypes), etc.

[0166] (3) Use the macros provided by the autonomous driving platform framework to register a message conversion plugin (REGISTER_PLUGING). The code example can include the plugin class name, and can also include message conversion parameters such as Messageconverter. See below:

[0167] One implementation of the source file lidar_pointcloud.cc may include message conversion logic. The code for this lidar message conversion logic may include message input types (InputTypes), output types (OutputTypes), and specific message conversion functions. For example, it may convert coordinates, intensity, and timestamps from the radar point cloud into a specified format such as floating-point numbers, rounded numbers, or integers.

[0168] The pluggable message conversion framework of this disclosure improves development efficiency by inheriting the message conversion base class. Users do not need to worry about the framework of the autonomous driving platform and the communication interface of ROS. They only need to implement the message conversion function and configure the corresponding channel to receive messages sent by ROS in various modules of the autonomous driving platform, further improving development efficiency.

[0169] The ROS environment self-discovery mechanism of this disclosure can identify multiple ROS environments and pass the corresponding information to the underlying compilation system, using the correct code during compilation, and has strong versatility.

[0170] The embodiments disclosed herein can adapt the communication interface of ROS, such as ROS2, through a communication middleware, such as ROS_bridge, to realize the path of messages from the framework of the autonomous driving platform to ROS_bridge to ROS, and from ROS to ROS_bridge to the framework of the autonomous driving platform.

[0171] This embodiment of the disclosure, based on pluggable message conversion logic, decouples the message conversion logic and the communication interface, thereby improving development efficiency and reducing code management difficulty.

[0172] This disclosure describes a method for developing self-discovery and configuration capabilities for ROS environments based on Bazel repository rules, which can be adapted to multiple ROS versions.

[0173] Figure 11 This is a schematic diagram of a message conversion plugin generation apparatus 1100 according to an embodiment of the present disclosure. The apparatus 1100 may include:

[0174] The message conversion plugin acquisition module 1110 is used to acquire the basic file of the message conversion plugin, which is used to generate the message conversion plugin in the bridging middleware; wherein, the message conversion plugin is used to perform message conversion between the first frame and the second frame.

[0175] The message conversion plugin compilation module 1120 is used to compile the basic files of the message conversion plugin and generate the message conversion plugin in the bridging middleware.

[0176] In one implementation, the message conversion plugin is used to convert a first message from the first frame into a second message from the second frame, and / or to convert a second message from the second frame into a first message from the first frame.

[0177] Figure 12 This is a schematic diagram of the structure of a message conversion plugin generation apparatus 1200 according to another embodiment of the present disclosure. The apparatus 1200 includes: a message conversion plugin acquisition module 1210 and a message conversion plugin compilation module 1220. The functions of these modules are the same as those of the modules in the message conversion plugin generation apparatus of the above embodiment. In one embodiment, the message conversion plugin generation apparatus further includes:

[0178] The first frame acquisition module 1230 is used to acquire the basic file of the first frame, which is used to generate the bridging middleware between the first frame and the second frame.

[0179] The first framework compilation module 1240 is used to compile the basic files of the first framework to generate the bridging middleware.

[0180] In one implementation, it further includes:

[0181] The inspection module 1250 is used to check whether the first frame has been installed in the target path;

[0182] The distribution acquisition module 1260 is used to acquire the distribution information of the first framework if the first framework is already installed in the target path. The distribution information of the first framework is used to acquire the basic files of the first framework.

[0183] In one implementation, it further includes:

[0184] The header file generation module 1270 is used to generate a header file containing the release information, which is used to enable the compiled bridging middleware to adapt to the communication interface of different versions of the first framework.

[0185] In one embodiment, the first frame acquisition module 1230 further includes:

[0186] Submodule 1231 is used to collect the header files and dynamic libraries of the first framework based on the release information of the first framework.

[0187] The rule base generation submodule 1232 is used to generate the rule base corresponding to the first framework based on the header file and the dynamic library using the set template. This rule base is used to compile and generate the bridging middleware.

[0188] In one implementation, the first framework compilation module 1240 is used to compile and generate an executable file of the bridging middleware using the header file, dynamic library and rule base corresponding to the first framework. The executable file of the bridging middleware includes message conversion base classes corresponding to the basic units of the first framework and the basic units of the second framework. The message conversion base class is used to support the message communication interface of the message conversion plugin.

[0189] In one implementation, the basic files of the message conversion plugin include one or more of the following: a compilation description file, a configuration file, a plugin description file, a header file, and a source file;

[0190] The compilation description file is used to describe the source code and / or compilation method of the message conversion plugin;

[0191] This configuration file contains information about the input and / or output channels of the message conversion plugin;

[0192] This plugin description file describes the dynamic libraries that this message conversion plugin needs to load;

[0193] In one implementation, the header file of the message conversion plugin includes one or more of the following: the base class that the message conversion plugin inherits from, the types of the input messages and / or output messages of the message conversion plugin, and the function definitions of the message conversion plugin;

[0194] The source files for this message conversion plugin include the message conversion logic.

[0195] In one embodiment, the conversion plugin acquisition module 1210 includes:

[0196] Import submodule 1211, which is used to import the header file of this message conversion plugin;

[0197] Inherit submodule 1212, which is used to inherit the message conversion base class in the header file of this message conversion plugin;

[0198] Define submodule 1213, which is used to define the conversion function in the header file of the message conversion plugin; wherein the message conversion logic of the conversion function is in the source file of the message conversion plugin;

[0199] Register submodule 1214, which is used to register this message conversion plugin.

[0200] In one implementation, the message conversion plugin compilation module 1220 is used to compile and generate a dynamic library of the message conversion plugin based on the basic files of the message conversion plugin. The dynamic library of the message conversion plugin is used to inherit the message conversion base class of the message conversion plugin and support the message conversion logic of the message conversion plugin.

[0201] Figure 13 This is a schematic diagram of a message conversion device 1300 according to an embodiment of the present disclosure. The device 1300 may include:

[0202] The receiving module 1310 is used to receive the message to be converted from the first frame or the second frame through the bridging middleware;

[0203] Module 1320 is invoked to call the corresponding message conversion plugin to perform message conversion between the first and second frames based on the message to be converted, according to the bridging middleware.

[0204] Figure 14 This is a schematic diagram of the structure of a message conversion device 1400 according to another embodiment of the present disclosure. The device 1400 includes a receiving module 1410 and a calling module 1420. The functions of these modules are the same as those of the modules in the message conversion device of the above embodiment. In one embodiment, the receiving module 1410 includes:

[0205] Sub-module 1411 is created for creating the subscriber of the first frame through this bridging middleware;

[0206] The first message receiving submodule 1412 is used to receive the first message from the first frame through the subscriber.

[0207] In one implementation, the calling module 1420 includes:

[0208] The first message call submodule 1421 is used to call the message conversion plugin corresponding to the topic information of the first message through the subscription client to convert the first message into a second message;

[0209] The write end creation submodule 1422 is used to create the write end of the first frame through the bridging middleware;

[0210] The second message sending submodule 1423 is used to send the second message to the second frame through the writing end.

[0211] In one embodiment, the receiving module 1410 includes:

[0212] The reading end creates a submodule 1413, which is used to create the reading end of the second frame through the bridging middleware;

[0213] The second message receiving module 1414 is used to receive a second message from the second frame through the reading end.

[0214] In one implementation, the calling module 1420 includes:

[0215] The second message call submodule 1424 is used to call the message conversion plugin corresponding to the channel information of the second message through the reading end, and convert the second message into the first message;

[0216] The publishing end creates submodule 1425, which is used to create the publishing end of the first framework through this bridging middleware;

[0217] The first message sending submodule 1426 is used to send the first message to the first framework through the publishing end.

[0218] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0219] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0220] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0221] Figure 15 A schematic block diagram of an example electronic device 1500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0222] like Figure 15 As shown, device 1500 includes a computing unit 1501, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 1502 or a computer program loaded from storage unit 1508 into random access memory (RAM) 1503. The RAM 1503 may also store various programs and data required for the operation of device 1500. The computing unit 1501, ROM 1502, and RAM 1503 are interconnected via bus 1504. Input / output (I / O) interface 1505 is also connected to bus 1504.

[0223] Multiple components in device 1500 are connected to I / O interface 1505, including: input unit 1506, such as keyboard, mouse, etc.; output unit 1507, such as various types of monitors, speakers, etc.; storage unit 1508, such as disk, optical disk, etc.; and communication unit 1509, such as network card, modem, wireless transceiver, etc. Communication unit 1509 allows device 1500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0224] The computing unit 1501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1501 performs the various methods and processes described above, such as the method for generating a message conversion plugin or a message conversion method. For example, in some embodiments, the method for generating a message conversion plugin or a message conversion method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1508. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1500 via ROM 1502 and / or communication unit 1509. When the computer program is loaded into RAM 1503 and executed by the computing unit 1501, one or more steps of the method for generating a message conversion plugin or a message conversion method described above can be performed. Alternatively, in other embodiments, the computing unit 1501 may be configured by any other suitable means (e.g., by means of firmware) to perform a message conversion plugin generation method or a message conversion method.

[0225] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0226] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0227] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0228] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0229] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0230] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0231] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0232] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.< / inputmsgptr>

Claims

1. A method for generating a message conversion plugin, comprising: The basic files of the message conversion plugin are obtained. These files are used to generate the message conversion plugin in the bridging middleware. The message conversion plugin is used to perform message conversion between the first and second frames. The basic files include a header file and source files. The header file inherits from a message conversion base class and defines conversion functions. The message conversion base class supports the message communication interface of the message conversion plugin. The source files include the message conversion logic of the conversion functions. Different types of message conversion plugins are used to convert different types of messages. The bridging middleware is used to call the message conversion plugin corresponding to the message to be converted based on the different types of messages to be converted. Compile the basic files of the message conversion plugin and generate the message conversion plugin in the bridging middleware.

2. The method according to claim 1, wherein, The message conversion plugin is used to convert a first message from the first frame into a second message from the second frame, and / or to convert a second message from the second frame into a first message from the first frame.

3. The method according to claim 1, wherein, The method further includes: Obtain the basic file of the first framework, which is used to generate the bridging middleware between the first framework and the second framework; The basic files of the first framework are compiled to generate the bridging middleware.

4. The method according to claim 3, further comprising: Check if the first frame is already installed in the target path; If the first framework is already installed in the target path, obtain the release information of the first framework. The release information of the first framework is used to obtain the basic files of the first framework.

5. The method according to claim 4, further comprising: Generate a header file containing the release information, which is used to enable the compiled bridging middleware to adapt to the communication interface of different versions of the first framework.

6. The method according to any one of claims 3 to 5, wherein, Obtaining the basic files of the first framework also includes: Based on the release information of the first framework, collect the header files and dynamic libraries of the first framework; Based on the header file and the dynamic library, a rule library corresponding to the first framework is generated using a set template. The rule library is used to compile and generate the bridging middleware.

7. The method according to any one of claims 3 to 5, wherein, Compiling the basic files of the first framework to generate the bridging middleware includes: Using the header file, dynamic library, and rule base corresponding to the first framework, the executable file of the bridging middleware is compiled and generated. The executable file of the bridging middleware includes message conversion base classes corresponding to the basic units of the first framework and the basic units of the second framework.

8. The method according to any one of claims 1 to 5, wherein, The basic files of the message conversion plugin also include one or more of the following: compilation description file, configuration file, and plugin description file; The compilation description file is used to describe the source code and / or compilation method corresponding to the message conversion plugin; The configuration file contains information about the input and / or output channels of the message conversion plugin; The plugin description file is used to describe the dynamic libraries that the message conversion plugin needs to load.

9. The method according to claim 8, wherein, The header file of the message conversion plugin also includes one or more of the following: the types of input and / or output messages of the message conversion plugin, and the function definitions of the message conversion plugin.

10. The method according to claim 8, wherein, Obtain the basic files for the message conversion plugin, including: Include the header file of the aforementioned message conversion plugin; In the header file of the message conversion plugin, inherit the message conversion base class; In the header file of the message conversion plugin, a conversion function is defined; wherein, the message conversion logic of the conversion function is in the source file of the message conversion plugin; Register the aforementioned message conversion plugin.

11. The method according to claim 8, wherein, Compile the basic files of the message conversion plugin to generate the message conversion plugin, including: Based on the basic files of the message conversion plugin, a dynamic library for the message conversion plugin is compiled and generated. The dynamic library of the message conversion plugin is used to inherit the message conversion base class of the message conversion plugin and support the message conversion logic of the message conversion plugin.

12. A message conversion method, comprising: Receive the message to be converted from the first frame or the second frame through the bridging middleware; The bridging middleware calls the corresponding message conversion plugin to perform message conversion between the first and second frames based on the message to be converted. The message conversion plugin is generated using the message conversion plugin generation method described in any one of claims 1-11.

13. The method according to claim 12, wherein, Receive the message to be converted from the first or second frame through the bridging middleware, including: The subscription end of the first frame is created through the bridging middleware; The first message is received from the first framework through the subscription terminal.

14. The method according to claim 13, wherein, The bridging middleware, based on the message to be converted, invokes the corresponding message conversion plugin to perform message conversion between the first and second frames, including: The subscription client calls the message conversion plugin corresponding to the topic information of the first message to convert the first message into a second message; The write end of the first frame is created through the bridging middleware; The second message is sent to the second frame through the writing end.

15. The method according to any one of claims 12 to 14, wherein, Receive the message to be converted from the first or second frame through the bridging middleware, including: The reading end of the second frame is created through the bridging middleware; The second message from the second frame is received through the reading end.

16. The method according to claim 15, wherein, The bridging middleware, based on the message to be converted, invokes the corresponding message conversion plugin to perform message conversion between the first and second frames, including: The message conversion plugin corresponding to the channel information of the second message is invoked by the reading end to convert the second message into the first message; The publishing end of the first framework is created through the bridging middleware; The first message is sent to the first framework through the publishing terminal.

17. A device for generating a message conversion plugin, comprising: A message conversion plugin acquisition module is used to acquire the basic files of message conversion plugins. These basic files are used to generate message conversion plugins in the bridging middleware. The message conversion plugins are used to perform message conversion between the first and second frames. The basic files of the message conversion plugins include header files and source files. The header files inherit from a message conversion base class and define conversion functions. The message conversion base class supports the message communication interface of the message conversion plugins. The source files of the message conversion plugins include the message conversion logic of the conversion functions. Different types of message conversion plugins are used to convert different types of messages. The bridging middleware is used to call the message conversion plugin corresponding to the message to be converted based on the different types of messages to be converted. The message conversion plugin compilation module is used to compile the basic files of the message conversion plugin and generate the message conversion plugin in the bridging middleware.

18. The apparatus according to claim 17, wherein, The message conversion plugin is used to convert a first message from the first frame into a second message from the second frame, and / or to convert a second message from the second frame into a first message from the first frame.

19. The apparatus according to claim 17, wherein, The device further includes: The first frame acquisition module is used to acquire the basic file of the first frame, and the basic file of the first frame is used to generate the bridging middleware between the first frame and the second frame. The first framework compilation module is used to compile the basic files of the first framework to generate the bridging middleware.

20. The apparatus of claim 19, further comprising: The inspection module is used to check whether the first frame has been installed in the target path; The release acquisition module is used to acquire the release information of the first framework if the first framework is already installed in the target path. The release information of the first framework is used to acquire the basic files of the first framework.

21. The apparatus of claim 20, further comprising: A header file generation module is used to generate a header file containing the release information. The header file containing the release information is used to enable the compiled bridging middleware to adapt to the communication interface of different versions of the first framework.

22. The apparatus according to any one of claims 19 to 21, wherein, The first framework acquisition module also includes: The collection submodule is used to collect the header files and dynamic libraries of the first framework based on the release information of the first framework. The rule base generation submodule is used to generate a rule base corresponding to the first framework based on the header file and the dynamic library using a set template. The rule base is used to compile and generate the bridging middleware.

23. The apparatus according to any one of claims 19 to 21, wherein, The first framework compilation module is used to compile and generate the executable file of the bridging middleware using the header file, dynamic library and rule base corresponding to the first framework. The executable file of the bridging middleware includes message conversion base classes corresponding to the basic units of the first framework and the basic units of the second framework.

24. The apparatus according to any one of claims 17 to 21, wherein, The basic files of the message conversion plugin also include one or more of the following: compilation description file, configuration file, and plugin description file; The compilation description file is used to describe the source code and / or compilation method corresponding to the message conversion plugin; The configuration file contains information about the input and / or output channels of the message conversion plugin; The plugin description file is used to describe the dynamic libraries that the message conversion plugin needs to load.

25. The apparatus according to claim 24, wherein, The header file of the message conversion plugin also includes one or more of the following: the types of input and / or output messages of the message conversion plugin, and the function definitions of the message conversion plugin.

26. The apparatus according to claim 24, wherein, The message conversion plugin acquisition module includes: Import a submodule to import the header file of the message conversion plugin; An inheritable submodule is used to inherit the message conversion base class in the header file of the message conversion plugin; Define a submodule for defining conversion functions in the header file of the message conversion plugin; wherein the message conversion logic of the conversion functions is in the source file of the message conversion plugin; The registration submodule is used to register the message conversion plugin.

27. The apparatus according to claim 24, wherein, The message conversion plugin compilation module is used to compile and generate a dynamic library for the message conversion plugin based on the basic files of the message conversion plugin. The dynamic library of the message conversion plugin is used to inherit the message conversion base class of the message conversion plugin and support the message conversion logic of the message conversion plugin.

28. A message conversion device, comprising: The receiving module is used to receive messages to be converted from the first frame or the second frame through the bridging middleware; The calling module is used to call the corresponding message conversion plugin to perform message conversion between the first frame and the second frame based on the message to be converted through the bridging middleware; The message conversion plugin is generated using the message conversion plugin generation method described in any one of claims 1-11.

29. The apparatus according to claim 28, wherein, The receiving module includes: A subscription creation submodule is used to create a subscription for the first framework through the bridging middleware; The first message receiving submodule is used to receive a first message from the first framework through the subscription terminal.

30. The apparatus according to claim 29, wherein, The calling module includes: The first message invocation submodule is used to invoke the message conversion plugin corresponding to the topic information of the first message through the subscription terminal to convert the first message into a second message; A write-end creation submodule is used to create the write end of the first frame through the bridging middleware; The second message sending submodule is used to send the second message to the second frame through the writing end.

31. The apparatus according to any one of claims 28 to 30, wherein, The receiving module includes: A submodule for creating a reading end is used to create a reading end for the second frame through the bridging middleware; The second message receiving module is used to receive a second message from the second frame through the reading end.

32. The apparatus according to claim 31, wherein, The calling module includes: The second message invocation submodule is used to invoke the message conversion plugin corresponding to the channel information of the second message through the reading end to convert the second message into the first message; The publishing end creates a submodule, which is used to create the publishing end of the first framework through the bridging middleware; The first message sending submodule is used to send the first message to the first framework through the publishing end.

33. An electronic device, comprising: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-16.

34. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-16.

35. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-16.

Images