A method for adapting autonomous driving middleware and a machine-readable storage medium

Abstract

The present invention provides an autonomous driving middleware adaptation method and a machine-readable storage medium, which belong to the technical field of autonomous driving middleware. The autonomous driving middleware adaptation method includes: using a predefined message interface program to generate corresponding encapsulation layer codes for different autonomous driving middleware, so that the application layer software calls each autonomous driving middleware in a consistent manner, wherein different fixed templates are provided in the message interface program, each of which corresponds to one autonomous driving middleware, and each of which is used to reference the interface file generated by the corresponding autonomous driving middleware, and use the specified namespace to refer to objects in different namespaces. The autonomous driving middleware adaptation method of the present invention enables upper-layer applications to access objects in different namespaces of various autonomous driving middlewares through the same file name and namespace.

Description

Technical Field

[0001] The present invention relates to the technical field of autonomous driving middleware, and in particular to an autonomous driving middleware adaptation method and a machine-readable storage medium. Background Art

[0002] The autonomous driving middleware is essentially a software framework between the upper-layer applications and the underlying systems. It is a platform for managing, allocating and scheduling software and hardware resources, and plays a key role in decoupling software and hardware. It provides the environment required for the development and operation of upper-layer application software, making it easier for developers to develop and integrate autonomous driving software quickly, efficiently and flexibly.

[0003] The mainstream autonomous driving middlewares at present include ROS, ROS2, cyber RT, and Adaptive Autosar. The original intention of ROS (Robot Operating System) is to provide a development environment and corresponding tools for scientific research robots. Autonomous driving is essentially an application field of robot research. Because of its defects in real-time, reliability, scalability, embedded transplantation, etc., ROS is generally only used in the process of rapid development of product prototypes. ROS2 is an upgraded version of ROS, free and open source. Currently, there are few mass production applications, and it is still lacking in security support, technical maturity and real-time domain. Cyber ​​RT is a middleware developed by Baidu Apollo, designed for unmanned driving, and deeply customized based on the current status of unmanned driving business. Baidu has now open-sourced Cyber ​​RT for use by the autonomous driving team. The AutoSAR standard defines the standard description of models, components, and interfaces (ARXML files), and software vendors provide implementations based on the AUTOSAR standard. Adaptive Autosar is based on object-oriented development in C++ language, providing good support for large-scale programming and encapsulation.

[0004] Different middleware software may be used in different development stages of autonomous driving projects. At the beginning of the project, most simulation tests and solution verification are performed through simulators, and the free open source middleware ROS is generally used at this time. As the project progresses, the solution test moves from the simulator to the actual vehicle. Considering the mass production requirements, the middleware needs to switch to software that can meet the mass production requirements. Therefore, if the upper-layer application software of the middleware can adapt to different middleware systems, it will save the need to change the upper-layer application software.

[0005] Currently, there is no software adaptation layer that can adapt to different middleware. Different adaptation requirements need to be made in version iterations according to different middleware. For example, there is a problem that upper-level applications cannot access different middleware with the same file name and namespace. Summary of the invention

[0006] An objective of the first aspect of the present invention is to provide an autonomous driving middleware adaptation method, which enables upper-layer applications to access objects in different namespaces of various autonomous driving middlewares through the same file name and namespace.

[0007] A further object of the present invention is to solve the problem of inconsistent codes of message times obtained by different autonomous driving middleware during message conversion.

[0008] Another object of the present invention is to unify the interfaces of different types of autonomous driving middleware so that they can be applied to the adaptation layer code framework.

[0009] An object of the second aspect of the present invention is to provide a machine-readable storage medium for implementing the above-mentioned autonomous driving middleware adaptation method.

[0010] In particular, the present invention provides an autonomous driving middleware adaptation method, comprising:

[0011] Use the predefined message interface program to generate the corresponding encapsulation layer code for different autonomous driving middleware, so that the application layer software can call each autonomous driving middleware in a consistent way.

[0012] Different fixed templates are provided in the message interface program, each of which corresponds to an autonomous driving middleware. Each of the fixed templates is used to reference the interface file generated by the corresponding autonomous driving middleware, and use a specified namespace to refer to objects in different namespaces.

[0013] Optionally, the autonomous driving middleware adaptation method further includes:

[0014] A predefined message conversion interface program is used to convert different messages of the autonomous driving middleware into messages that are independent of the middleware.

[0015] Optionally, the step of converting different messages of the autonomous driving middleware into messages unrelated to the middleware using a predefined message conversion interface program comprises:

[0016] Obtaining time information of different autonomous driving middleware; wherein,

[0017] The message conversion interface program is used to return different nanosecond fields depending on whether the destination object of the autonomous driving middleware contains a target field.

[0018] Optionally, the message conversion interface program includes multiple template methods with the same name, each of which corresponds to an autonomous driving middleware and is used to return a corresponding nanosecond field according to the target field contained in the destination object of the autonomous driving middleware to which it corresponds.

[0019] Optionally, the autonomous driving middleware adaptation method further includes:

[0020] Receive a target message to be published from a business module in the autonomous driving application system, where the type of the target message to be published is a message unrelated to the middleware;

[0021] Converting the target to-be-published message into a middleware target to-be-published message of a target autonomous driving middleware through the message conversion interface program;

[0022] The middleware target message to be published is converted into a middleware-independent middleware-independent target message to be published through the message conversion interface program, so that each business model subscribing to the target message to be published can receive the middleware-independent target message to be published.

[0023] Optionally, the autonomous driving middleware adaptation method further includes:

[0024] Define a parameter interface class, which is used to provide an interface for setting calibration parameters of autonomous driving, an interface for obtaining autonomous driving parameters, and an interface for monitoring changes in the autonomous driving parameters;

[0025] Each autonomous driving middleware inherits the parameter interface class to implement the corresponding interface functions.

[0026] Optionally, the autonomous driving middleware adaptation method further includes:

[0027] Define a log interface class, which is used to provide an interface for recording program running logs;

[0028] Each autonomous driving middleware inherits the log interface class to implement the corresponding interface functions.

[0029] Optionally, the autonomous driving middleware adaptation method further includes:

[0030] Define a clock interface class, which is used to provide an interface for obtaining current time and time conversion;

[0031] Each autonomous driving middleware inherits the clock interface class to implement the corresponding interface functions.

[0032] Optionally, a general driver interface class is defined to drive each application class to execute at a preset frequency, and each application class corresponds to an executable program for autonomous driving;

[0033] Each autonomous driving middleware inherits the driver interface class to implement corresponding interface functions.

[0034] In particular, the present invention also provides a machine-readable storage medium having a machine executable program stored thereon, and when the machine executable program is executed by a processor, the autonomous driving middleware adaptation method according to any one of the above items is implemented.

[0035] According to one embodiment of the present invention, in order to address the problems of inconsistent file names and inconsistent object name spaces of interface files generated by different autonomous driving middleware, a fixed template is set to generate encapsulation layer codes corresponding to different autonomous driving middleware, so that upper-level applications can access objects in different name spaces of each autonomous driving middleware through the same file name and name space.

[0036] According to one embodiment of the present invention, by returning different nanosecond fields according to whether the destination object of the autonomous driving middleware contains a target field, the problem of inconsistent codes of message times obtained by different autonomous driving middleware during message conversion can be solved.

[0037] According to one embodiment of the present invention, a message conversion method between each autonomous driving middleware and the autonomous driving application system is provided. By converting messages from specific middleware message types to message types unrelated to the middleware, message interaction is performed based on a publish-subscribe model, which enables message conversion and transmission between the autonomous driving application system and the autonomous driving middleware.

[0038] According to one embodiment of the present invention, in order to address the problem of inconsistent APIs between certain autonomous driving middleware and other middleware, a set of unified interfaces is defined to achieve the unification of interfaces of different types of autonomous driving middleware, which can be applied to the adaptation layer code framework.

[0039] Based on the following detailed description of specific embodiments of the present invention in conjunction with the accompanying drawings, those skilled in the art will become more aware of the above and other objects, advantages and features of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Hereinafter, some specific embodiments of the present invention will be described in detail in an exemplary and non-limiting manner with reference to the accompanying drawings. The same reference numerals in the accompanying drawings indicate the same or similar components or parts. It should be understood by those skilled in the art that these drawings are not necessarily drawn to scale. In the accompanying drawings:

[0041] Figure 1 is a flowchart of an autonomous driving middleware adaptation method according to an embodiment of the present invention;

[0042] Figure 2is a flowchart of an autonomous driving middleware adaptation method according to another embodiment of the present invention.

[0043] Reference numerals: DETAILED DESCRIPTION

[0044] Figure 1 FIG. 1 is a flow chart of an autonomous driving middleware adaptation method according to an embodiment of the present invention. Figure 1 As shown, in one embodiment, the autonomous driving middleware adaptation method includes:

[0045] Step S100, using a predefined message interface program to generate corresponding encapsulation layer codes for different autonomous driving middlewares, so that the application layer software can call each autonomous driving middleware in a consistent manner, wherein different fixed templates are provided in the message interface program, each fixed template corresponds to an autonomous driving middleware, each fixed template is used to reference the interface file generated by the corresponding autonomous driving middleware, and use the specified namespace to refer to objects in different namespaces. In other words, the same name is used to refer to objects with the same meaning but different namespaces in each autonomous driving middleware.

[0046] For example, in ROS, the common autonomous driving middleware for vehicles, the interface is defined in msg, srv, and action files, which can generate corresponding C++ interface files. ROS1 and ROS2 will generate similar, but not identical interface files, and the calling method of the upper-level software will be different. For example, the file names generated by ROS1 and ROS2 are inconsistent, resulting in the upper-level software needing to use different codes to reference the generated interface files. The namespaces of the C++ objects generated by ROS1 and ROS2 are also inconsistent, resulting in the upper-level software needing to use different codes to reference the generated C++ objects.

[0047] In view of this situation, according to step S100, we can reference different C++ interface files generated by ROS1 and ROS2 through different fixed templates in the message interface program, and use aliases (i.e. the above-mentioned specified names) to refer to C++ objects with different namespaces. In this way, the upper-layer software can reference the wrapper layer C++ interface file (i.e. the message interface program) with the same name, and access the specific C++ object through a consistent access method.

[0048] In order to solve the problems of inconsistent file names and inconsistent object namespaces of interface files generated by different autonomous driving middleware, this embodiment generates encapsulation layer codes corresponding to different autonomous driving middleware by setting a fixed template, so that upper-level applications can access objects in different namespaces of each autonomous driving middleware through the same file name and namespace.

[0049] Figure 2is a flow chart of an autonomous driving middleware adaptation method according to another embodiment of the present invention. Figure 2 As shown, the method also includes:

[0050] Step S200, using a predefined message conversion interface program to convert messages of different autonomous driving middleware into messages that are independent of the middleware. This step is used to complete message conversion (codec).

[0051] In one embodiment, step S200 includes:

[0052] Obtain time information of different autonomous driving middleware; wherein the message conversion interface program is used to return different nanosecond fields according to whether the destination object of the autonomous driving middleware contains a target field. For example, the message conversion interface program includes multiple template methods with the same name, each template method corresponds to an autonomous driving middleware, that is, a template method is only valid for one autonomous driving middleware. Each template method is used to return the corresponding nanosecond field according to the target field contained in the destination object of the autonomous driving middleware to which it corresponds.

[0053] Taking ROS1 and ROS2 as examples, the header class fields generated by the two are inconsistent (ROS1 header has a seq field, ROS2 does not) and the field names of the Time class are inconsistent (ROS1's nanosecond field name is nsec, ROS2's is nanosec). The header class fields of ROS1 and ROS2 are shown in the following code:

[0054] / / ROS1

[0055] struct Header

[0056] {

[0057] uint32_t seq;

[0058] Time stamp;

[0059] std::string frame_id;

[0060] };

[0061] struct Time

[0062] {

[0063] uint32_t sec;

[0064] uint32_t nsec;

[0065] };

[0066] / / ROS2

[0067] struct Header

[0068] {

[0069] Time stamp;

[0070] std::string frame_id;

[0071] };

[0072] struct Time

[0073] {

[0074] uint32_t sec;

[0075] uint32_t nanosec;

[0076] };

[0077] According to the above method, two template methods with the same name can be defined, corresponding to ROS1 and ROS2 respectively, which are used to return different nanosecond fields according to whether the header object of ROS1 or ROS2 has a seq field, that is, nsec is returned when seq is included, and nanosec is returned when seq is not included. The above method can be implemented by using the SFINAE technology (Substitution Failure Is NotAn Error) of C++ templates, which can be implemented through the following code:

[0078] template<class T,typename=void>

[0079] struct has_seq:std::false_type

[0080] {

[0081] };

[0082] template<typename T>

[0083] struct has_seq <T,decltype(std::declval <t>().seq,void())>:std::true_type

[0084] {

[0085] };

[0086] template<typename T,typename std::enable_if_t<has_seq <t>::value,uint32_t>=0>

[0087] static uint32_t GetNanosec(const T&unit)

[0088] {

[0089] return unit.stamp.nsec;

[0090] }

[0091] template<typename T,typename std::enable_if_t<!has_seq <t>::value,uint32_t>=0>

[0092] static uint32_t GetNanosec(const T&unit)

[0093] {

[0094] return unit.stamp.nanosec;

[0095] }

[0096] The message conversion interface program is used to convert the middleware message type and the platform-independent message type to each other. In actual use, if you need to obtain the time of the message, you need to access the nanosecond member of the time class. However, since the member names of different autonomous driving middleware are different, the code for obtaining the message time is inconsistent. This embodiment can solve the problem of inconsistent code for message time obtained by different autonomous driving middleware during the message conversion process by returning different nanosecond fields according to whether the destination object of the autonomous driving middleware contains the target field.

[0097] Since the APIs of some middleware (such as ROS1 and ROS2) are inconsistent with other middleware, the upper-layer application software needs to implement the middleware interface calls in different ways, which requires switching middleware at a great cost or maintaining multiple middleware at the same time.

[0098] The present invention uses C++ type erasure technology and templates to erase type class implementations, that is, to abstract the common behaviors of various autonomous driving middlewares and define the same set of interfaces for them, mainly including the publishing and subscription of the following messages, setting of calibration parameters, acquisition and monitoring of parameter changes, clocks, logs and drivers running at a certain frequency, etc.

[0099] like Figure 2 As shown, in one embodiment, the method further includes:

[0100] Step S300, receiving a target message to be published of a business module in the autonomous driving application system, where the type of the target message to be published is a middleware-independent (also referred to as a platform-independent) message.

[0101] Step S310, converting the target message to be published into the middleware target message to be published of the target autonomous driving middleware through the message conversion interface program.

[0102] Step S320, converting the middleware target message to be published into a middleware-independent message to be published that is independent of the middleware through the message conversion interface program, so that each business model subscribing to the target message to be published can receive the middleware-independent message to be published.

[0103] This embodiment provides a message conversion method between various autonomous driving middleware and autonomous driving application systems. By converting messages from specific middleware message types to message types unrelated to the middleware, and performing message interaction based on the publish-subscribe model, it is possible to achieve message conversion and transmission between the autonomous driving application system and the autonomous driving middleware.

[0104] like Figure 2 As shown, in one embodiment, the method further includes:

[0105] Step S400, defining a parameter interface class, a log interface class, a clock interface class and a driver interface class.

[0106] Step S500: Each autonomous driving middleware inherits the parameter interface class, log interface class, clock interface class and driver interface class to implement corresponding interface functions.

[0107] Furthermore, in step S400, the parameter interface class is used to provide an interface for setting calibration parameters of autonomous driving, an interface for obtaining autonomous driving parameters, and an interface for monitoring changes in autonomous driving parameters. The calibration parameters may be parameters such as the following distance and the expected speed.

[0108] In this embodiment, the parameter interface class inherited by the autonomous driving middleware can realize the functions of setting the interface of calibration parameters, obtaining autonomous driving parameters and monitoring changes in autonomous driving parameters.

[0109] The log interface class is used to provide an interface for recording program running logs. The clock interface class is used to provide an interface for obtaining the current time and time conversion.

[0110] This embodiment defines a log interface class and a clock interface class so that the autonomous driving middleware inherits the corresponding classes to implement the functions of recording program running logs and obtaining the current time and time conversion.

[0111] Furthermore, in step S400, the driving interface class is used to drive each application class to execute at a preset frequency, and each application class corresponds to an executable program for autonomous driving. The application class may include a perception module, a preset module, a planning module, and a control module for autonomous driving.

[0112] In this embodiment, the autonomous driving middleware inherits the driver interface class and can drive each application class to execute at a preset frequency.

[0113] In order to solve the problem of inconsistent APIs between some autonomous driving middleware and other middleware, this embodiment defines a unified set of interfaces to unify the interfaces of different types of autonomous driving middleware, which can be applied to the adaptation layer code framework.

[0114] The present invention also provides a machine-readable storage medium having a machine executable program stored thereon. When the machine executable program is executed by a processor, the autonomous driving middleware adaptation method according to any one of the above embodiments or combinations of embodiments is implemented.

[0115] At this point, those skilled in the art should recognize that, although multiple exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications that conform to the principles of the present invention can still be directly determined or derived based on the content disclosed in the present invention without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention should be understood and recognized as covering all these other variations or modifications.< / t> < / t> < / t>

Claims

1. A method for adapting an autonomous driving middleware, characterized in that: include: Use the predefined message interface program to generate the corresponding encapsulation layer code for different autonomous driving middleware, so that the application layer software can call each autonomous driving middleware in a consistent way. Different fixed templates are provided in the message interface program, each of the fixed templates corresponds to one of the autonomous driving middlewares, each of the fixed templates is used to reference an interface file generated by the corresponding autonomous driving middleware, and uses a specified namespace to refer to objects in different namespaces; Also includes: Using a predefined message conversion interface program, the messages of different autonomous driving middlewares are converted into messages that are independent of the middleware; The steps of converting different messages of the autonomous driving middleware into messages unrelated to the middleware using a predefined message conversion interface program include: Obtaining time information of different autonomous driving middleware; wherein, The message conversion interface program is used to return different nanosecond fields depending on whether the destination object of the autonomous driving middleware contains a target field.

2. The autonomous driving middleware adaptation method according to claim 1, characterized in that: The message conversion interface program includes multiple template methods with the same name, each of which corresponds to an autonomous driving middleware and is used to return the corresponding nanosecond field according to the target field contained in the destination object of the autonomous driving middleware to which it corresponds.

3. The autonomous driving middleware adaptation method according to any one of claims 1-2, characterized in that: Also includes: Receive a target message to be published from a business module in the autonomous driving application system, where the type of the target message to be published is a message unrelated to the middleware; Converting the target to-be-published message into a middleware target to-be-published message of a target autonomous driving middleware through the message conversion interface program; The middleware target message to be published is converted into a middleware-independent middleware-independent target message to be published through the message conversion interface program, so that each business model subscribing to the target message to be published can receive the middleware-independent target message to be published.

4. The autonomous driving middleware adaptation method according to claim 3, characterized in that: Also includes: Define a parameter interface class, which is used to provide an interface for setting calibration parameters of autonomous driving, an interface for obtaining autonomous driving parameters, and an interface for monitoring changes in the autonomous driving parameters; Each autonomous driving middleware inherits the parameter interface class to implement the corresponding interface functions.

5. The autonomous driving middleware adaptation method according to claim 4, characterized in that: Also includes: Define a log interface class, which is used to provide an interface for recording program running logs; Each autonomous driving middleware inherits the log interface class to implement the corresponding interface functions.

6. The autonomous driving middleware adaptation method according to claim 5, characterized in that: Also includes: Define a clock interface class, which is used to provide an interface for obtaining current time and time conversion; Each autonomous driving middleware inherits the clock interface class to implement the corresponding interface functions.

7. The autonomous driving middleware adaptation method according to claim 6, characterized in that: Define a general driver interface class for driving each application class to execute at a preset frequency, each of the application classes corresponding to an executable program for autonomous driving; Each autonomous driving middleware inherits the driver interface class to implement corresponding interface functions.

8. A machine-readable storage medium having a machine executable program stored thereon, wherein the machine executable program, when executed by a processor, implements the autonomous driving middleware adaptation method according to any one of claims 1 to 7.

Images