ROS-based driver node software design methods, devices, equipment, and media

Abstract

This application relates to the field of intelligent driving technology, and in particular to a ROS-based driver node software design method, apparatus, device, and medium. The method includes: acquiring at least one CAN raw data set; matching the corresponding target decoding device to decode the CAN raw data set according to its corresponding ID, obtaining decoded CAN data for each raw data set; acquiring the data category of each decoded CAN data set; and matching the corresponding message topic according to the data category of each decoded CAN data set to publish the corresponding decoded CAN data. This solves problems in related technologies such as inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects. By designing a three-layer software inheritance structure, it improves the efficiency and flexibility of EyeQ4 data processing based on ROS, as well as the convenience of algorithm development and testing.

Description

Technical Field

[0001] This application relates to the field of intelligent driving technology, and in particular to a method, apparatus, device and medium for designing drive node software based on ROS (Robot Operating System). Background Technology

[0002] With the rapid development of autonomous driving technology, the requirements for vision algorithm processors in intelligent driving systems are also increasing. ROS, as an open-source robot software development framework, provides developers with a wealth of tools and libraries, supports multiple programming languages, and has high flexibility and scalability.

[0003] However, in the practical application of intelligent driving systems, there are still some problems in the parsing and distribution of CAN (Controller Area Network) output messages, data collection and playback, and data visualization of EyeQ4 devices. For example, there are problems such as inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects in related technologies, which limit the improvement of the performance of intelligent driving systems and urgently need to be solved. Summary of the Invention

[0004] This application provides a ROS-based method, apparatus, device, and medium for designing driver node software to solve problems such as inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects in related technologies.

[0005] The first aspect of this application provides a ROS-based driver node software design method, comprising the following steps:

[0006] Obtain at least one CAN raw data;

[0007] Match the target decoding device for each raw CAN data ID according to the corresponding ID of each raw CAN data, and decode the corresponding raw CAN data according to the target decoding device of each raw CAN data ID to obtain the decoded CAN data corresponding to each raw CAN data.

[0008] Obtain the data category of each decoded CAN data, match the corresponding message topic according to the data category of each decoded CAN data, and publish the corresponding decoded CAN data according to the message topic.

[0009] According to one embodiment of this application, after matching the corresponding message topic based on the data category of each decoded CAN data, the method further includes:

[0010] Obtain the ROS message library corresponding to the data category of each decoded CAN data;

[0011] Each decoded CAN data is encapsulated into its corresponding ROS message library, and the ROS message library containing the decoded CAN data is published to the corresponding message topic.

[0012] According to one embodiment of this application, the step of publishing the ROS message library encapsulated with decoded CAN data to the corresponding message topic further includes:

[0013] Identify the target ROS message library that encapsulates decoded CAN data into visualized data in all ROS message libraries;

[0014] CAN image information is generated based on the decoded CAN data in the target ROS message library, and the CAN image information is published to the corresponding visualization message topic.

[0015] According to one embodiment of this application, after obtaining the decoded CAN data corresponding to each raw CAN data, the method further includes:

[0016] Obtain CAN data subscription requirements;

[0017] The topic of the message to be published is determined based on the CAN data subscription requirements;

[0018] Based on the topic of the message to be published, the target CAN data is selected from all decoded CAN data and published.

[0019] According to one embodiment of this application, the target decoding device is a DBC protocol file.

[0020] According to the ROS-based driver node software design method of this application, at least one CAN raw data is acquired. Based on the corresponding ID of each CAN raw data, a corresponding target decoding device is matched to decode the CAN raw data, resulting in decoded CAN data for each CAN raw data. The data category of each decoded CAN data is obtained, and a corresponding message topic is matched based on the data category to publish the corresponding decoded CAN data. This solves the problems of inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects in related technologies. By designing a three-layer class software inheritance structure, the efficiency and flexibility of ROS-based EyeQ4 data processing, as well as the convenience of algorithm development and testing, are improved.

[0021] A second aspect of this application provides a ROS-based driver node software design apparatus, comprising:

[0022] The acquisition module is used to acquire at least one piece of raw CAN data.

[0023] The parsing module is used to match the target decoding device for each original data ID according to the corresponding ID of each original data, and to decode the corresponding original data according to the target decoding device of each original data ID, so as to obtain the decoded CAN data corresponding to each original data.

[0024] The matching module is used to obtain the data category of each decoded CAN data, match the corresponding message topic according to the data category of each decoded CAN data, and publish the corresponding decoded CAN data according to the message topic.

[0025] According to one embodiment of this application, after matching the corresponding message topic based on the data category of each decoded CAN data, the matching module further includes:

[0026] The first acquisition unit is used to acquire the ROS message library corresponding to the data category of each decoded CAN data;

[0027] The encapsulation unit is used to encapsulate each decoded CAN data into the corresponding ROS message library, and publish the ROS message library containing the decoded CAN data to the corresponding message topic.

[0028] According to one embodiment of this application, the packaging unit further includes:

[0029] The identification subunit is used to identify the target ROS message library for visualizing decoded CAN data encapsulated in all ROS message libraries.

[0030] The generation subunit is used to generate CAN image information based on the decoded CAN data in the target ROS message library, and publish the CAN image information to the corresponding visualization message topic.

[0031] According to one embodiment of this application, after obtaining the decoded CAN data corresponding to each original CAN data, the parsing module further includes:

[0032] The second acquisition unit is used to acquire CAN data subscription requests;

[0033] The determining unit is used to determine the topic of the message to be published based on the CAN data subscription requirements;

[0034] The filtering unit is used to filter out target CAN data from all decoded CAN data according to the topic of the message to be published, and to publish the target CAN data.

[0035] According to one embodiment of this application, the target decoding device is a DBC protocol file.

[0036] According to the ROS-based driver node software design apparatus of this application embodiment, at least one CAN raw data is acquired. Based on the corresponding ID of each CAN raw data, a corresponding target decoding device is matched to decode the corresponding CAN raw data, resulting in decoded CAN data for each CAN raw data. The data category of each decoded CAN data is acquired, and a corresponding message topic is matched based on the data category of each decoded CAN data to publish the corresponding decoded CAN data. This solves the problems of inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects in related technologies. By designing a three-layer class software inheritance structure, the efficiency and flexibility of ROS-based EyeQ4 data processing, as well as the convenience of algorithm development and testing, are improved.

[0037] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the ROS-based driver node software design method as described in the above embodiments.

[0038] A fourth aspect of this application provides a computer-readable storage medium storing computer instructions for causing the computer to execute the ROS-based driver node software design method as described in the above embodiments.

[0039] A fifth aspect of this application provides a computer program product, including a computer program that is executed to implement the ROS-based driver node software design method described in the above embodiments.

[0040] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0041] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0042] Figure 1 A flowchart illustrating a ROS-based driver node software design method according to an embodiment of this application;

[0043] Figure 2 This is a schematic diagram of the three-tier class inheritance relationship of driver node software according to an embodiment of this application;

[0044] Figure 3 This is a flowchart illustrating the processing of lane lines and target data according to an embodiment of this application;

[0045] Figure 4 This is a block diagram of a ROS-based driver node software design apparatus according to an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0047] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0048] The following description, with reference to the accompanying drawings, describes a ROS-based driver node software design method, apparatus, device, and medium according to embodiments of this application. Addressing the problems mentioned in the background art, such as inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects, this application provides a ROS-based driver node software design method. In this method, at least one CAN raw data is acquired. Based on the corresponding ID of each CAN raw data, a corresponding target decoding device is matched to decode the corresponding CAN raw data, resulting in decoded CAN data for each CAN raw data. The data category of each decoded CAN data is obtained, and a corresponding message topic is matched based on the data category of each decoded CAN data to publish the corresponding decoded CAN data. This solves the problems of inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects in related technologies. By designing a three-layer class software inheritance structure, the efficiency and flexibility of EyeQ4 data processing based on ROS, as well as the convenience of algorithm development and testing, are improved.

[0049] Specifically, before introducing the embodiments of this application, we will first introduce the software development framework involved in the embodiments of this application, such as the ROS (Robot Operating System). ROS provides a large number of toolkits and libraries to help software developers create robot applications. Its built-in libraries and tools can support the solution of problems including: device drivers, visualization, algorithm libraries, message sending, and package management. As an open-source system, ROS is very flexible in development, easy to extend and modify, and supports C++ and Python APIs. ROS can transmit data through low-level drivers such as Linux drivers and control motion through kinematic calculations using various algorithms. The above logic can be written by ourselves and encapsulated into a node, thereby being controlled through topics / services. The following detailed embodiments will illustrate the software design method of the EyeQ4 signal analysis driver node for the ROS-based intelligent driving system vision algorithm processor in this application.

[0050] Specifically, Figure 1 This is a flowchart illustrating a ROS-based driver node software design method provided in an embodiment of this application.

[0051] like Figure 1 As shown, this ROS-based driver node software design method includes the following steps:

[0052] In step S101, at least one piece of raw CAN data is acquired.

[0053] Specifically, such as Figure 2 As shown in the embodiment of this application, the user-designed EyeQ4 signal parsing driver node software for the intelligent driving system based on ROS adopts a three-layer inheritance software structure: the first layer, CAN data communication layer (CAN Interface Manager), whose main function is to be responsible for the communication of the underlying hardware; the second layer, data decoding layer (EyeQ4 Message Manager); and the third layer, data publishing layer (EyeQ4 ROS Publisher). Among them, EyeQ4Message Manager inherits the CAN Interface Manager class, and EyeQ4 ROS Publisher inherits the EyeQ4Message Manager class. Thus, the data processing of the vision sensor, the testing of the path planning algorithm, and the monitoring and visualization of the vehicle status can be realized through the three-layer inheritance structure.

[0054] Specifically, in this embodiment, at least one piece of raw CAN data is first obtained through the CAN Interface Manager layer, that is, the raw data frame received by the CAN interface is directly obtained. Then, the EyeQ4 Message Manager layer inherits the CAN Interface Manager class and performs the next operation on the raw CAN data. Since the CAN Interface Manager class does not depend on any decoding function or any ROS-related library, it can be directly ported to any application to be responsible for the function of receiving CAN data.

[0055] In step S102, the target decoding device for each original CAN data ID is matched according to the corresponding ID of each original CAN data, and the corresponding original CAN data is decoded according to the target decoding device for each original CAN data ID, so as to obtain the decoded CAN data corresponding to each original CAN data.

[0056] Specifically, in this embodiment of the EyeQ4 Message Manager, after inheriting the CAN Interface Manager class, each raw CAN data is decoded by a different decoder according to its ID. That is, based on the corresponding ID of at least one raw CAN data, the target decoding device for each raw data ID is matched respectively, so that the corresponding raw CAN data is decoded according to the target decoding device for each raw data ID, and the corresponding data is updated. Finally, the decoded CAN data corresponding to each raw CAN data is obtained. In the EyeQ4 Message Manager class, it does not depend on any ROS-related libraries and can be ported to other non-ROS applications to be responsible for decoding the CAN messages output by EyeQ4.

[0057] Preferably, to avoid requiring technical personnel to delve into the details of the underlying CAN protocol for application layer logic development, thereby improving development efficiency and system maintainability, the target decoding device in this embodiment can be a DBC (Database for CAN) protocol file. A DBC protocol file is a standard file format used to describe CAN bus communication specifications. It can store all the necessary information for data interaction on the CAN network in a structured manner, mainly including four parts: message definition, signal definition, node definition, and comments and version information. This allows for the use of a unified and standardized format to exchange CAN network configurations, enabling different development tools and software (such as Vector'sCANoe, CANalyzer, CANdb++, ETAS ISOLAR, or open-source tools) to understand and parse this information.

[0058] In step S103, the data category of each decoded CAN data is obtained, the corresponding message topic is matched according to the data category of each decoded CAN data, and the corresponding decoded CAN data is published according to the message topic.

[0059] According to one embodiment of this application, after matching the corresponding message topic according to the data category of each decoded CAN data, the method further includes: obtaining the ROS message library corresponding to the data category of each decoded CAN data; encapsulating each decoded CAN data into the corresponding ROS message library; and publishing the ROS message library encapsulated with the decoded CAN data to the corresponding message topic.

[0060] Specifically, Benru Figure 3 As shown, in this embodiment, the corresponding raw CAN data is decoded using the DBC protocol file in the EyeQ4 Message Manager layer. After obtaining the decoded CAN data corresponding to each raw CAN data, the data category of each decoded CAN data and the corresponding ROS message library are obtained through the EyeQ4 ROS Publisher. Each decoded CAN data is encapsulated into the corresponding ROS message library, and the ROS message library containing the decoded CAN data is published to the corresponding message topic to publish the corresponding decoded CAN data according to the message topic.

[0061] Specifically, in this embodiment, the EyeQ4 ROS Publisher, after inheriting the EyeQ4 Message Manager class, obtains the data category of each decoded CAN data and the corresponding ROS message library. For example, the data category of the decoded CAN data can be lane lines, target detection information, road edge detection information, etc. After a cycle of decoded CAN data transmission ends and all decoded CAN data has been updated, each decoded CAN data is encapsulated into the corresponding ROS message library. Each publisher then publishes the ROS message library containing the decoded CAN data to the corresponding message topic. In this embodiment, the EyeQ4 ROS driver node program creates multiple message topics to publish the corresponding decoded CAN data. The specific correspondence between the ROS message library of the decoded CAN data and the corresponding message topic is shown in Table 1.

[0062] Table 1

[0063]

[0064]

[0065] It should be noted that, in this embodiment, the message topic is the way all ROS message libraries (i.e., ROS nodes) transmit data. The ROS message library sends the corresponding decoded CAN data through the message topic (i.e., a ROS node publishes a message topic), and the ROS node also receives the corresponding decoded CAN data through the topic (i.e., a ROS node subscribes to a message topic). There are no other connections between ROS nodes. As long as the decoded CAN data type is correct, the decoded CAN data can be sent and read through the message topic. At the same time, the data structure of all messages is defined to be as consistent as possible with the content of the original CAN data output, including data point naming and hierarchical relationships.

[0066] According to one embodiment of this application, publishing a ROS message library containing decoded CAN data to a corresponding message topic further includes: identifying a target ROS message library that encapsulates decoded CAN data as visualization data in all ROS message libraries; generating CAN image information based on the decoded CAN data in the target ROS message library; and publishing the CAN image information to the corresponding visualization message topic.

[0067] Specifically, in this embodiment, after publishing the ROS message library containing the decoded CAN data to the corresponding message topic through the EyeQ4 ROS Publisher layer, if there is visualization data in all the decoded CAN data, the visualization data is encapsulated into the target ROS message library. Then, the EyeQ4 ROS Publisher layer generates the corresponding CAN image information based on the decoded CAN data (i.e., visualization data) in the target ROS message library. Finally, the CAN image information is published to the corresponding visualization message topic so that the CAN image information in the visualization topic can be displayed through the ROS built-in visualization tool Rviz.

[0068] According to one embodiment of this application, after obtaining the decoded CAN data corresponding to each original CAN data, the method further includes: obtaining CAN data subscription requirements; determining the topic of the message to be published based on the CAN data subscription requirements; filtering out the target CAN data from all decoded CAN data according to the topic of the message to be published, and publishing the target CAN data.

[0069] Specifically, in this embodiment of the application, after publishing each decoded CAN data to the corresponding message topic, the decoded CAN data subscription requirements can be obtained based on the data processing node, and the message topic to be published corresponding to each decoded CAN data can be determined based on the decoded CAN data subscription requirements. The target CAN data, i.e. the decoded CAN data subscription requirement database, can be selected from all decoded CAN data according to the message topic to be published, and the target CAN data can be published.

[0070] In summary, to facilitate a better understanding of the embodiments of this application by those skilled in the art, an application example will be described below, and the specific method is as follows:

[0071] First, the compilation and operation of the EyeQ4 ROS driver node in this application embodiment has the following system requirements: (1) The test system needs to use version 18.04 of the Ubuntu operating system; (2) The software project or system needs to be developed, compiled and run under the ROS Melodic version framework, wherein ROS Melodic supports the Ubuntu 18.04 operating system.

[0072] Next, compile the system code. (1) Create a ROS workspace, for example, named "catkin_ws"; (2) Create a "src" folder in the "catkin_ws" folder, and copy the ROS message library source code folder "EyeQ4_ROS" and the message topic definition folder "me_msg" to the "src" folder to get "catkin_ws / src / EyeQ4_ROS" and "catkin_ws / src / me_msg"; (3) Open the command line, enter the catkin_ws file directory, enter the command catkin_make, and wait for the compilation to succeed.

[0073] Next, real-time CAN data is received and processed through a three-layer inheritance structure. At least one raw CAN data point is obtained through the CANInterface Manager layer. The DBC protocol file in the EyeQ4 Message Manager layer decodes the ID corresponding to each raw CAN data point and updates the corresponding data, resulting in decoded CAN data for each raw CAN data point. The EyeQ4 ROS Publisher layer encapsulates all decoded CAN data into the corresponding ROS message library, which is then published by each publisher to the corresponding message topic in the ROS message library. If there is visually readable decoded CAN data, an image corresponding to the decoded CAN data is generated at this layer and published to the corresponding visual message topic. The main processing steps for CAN data include the following:

[0074] (1) Set the CAN port. Assuming the CAN data access port is can0, open the command line.

[0075] (2) Launch ROSCORE and open a new command line;

[0076] (3) Start the EyeQ4_ROS node, open a new command line, and the program node will run and begin publishing the decoded CAN data;

[0077] (4) Start rqt to check the CAN data transmission status after decoding. Open a new command line and enter: rqt. At this time, rqt will start, and information such as ROS message library, message topic and decoded CAN data will be displayed in real time.

[0078] Then, in the case where there is no actual CAN device connected and the recorded CAN data stream needs to be used, the following method can be used to process the callback data using the decoded CAN data. The main steps are as follows:

[0079] (1) Configure the virtual CAN port vcan0:

[0080] (2) Use canplayer to replay the CAN data stream. At this time, vcan0 will generate a data stream just like a real CAN port. Here, 'vcan0=can0, vcan0=can1' means that the data generated by can0 and can1 in the original CAN data is mapped to vcan0.

[0081] (3) Using the above method for receiving real-time CAN data, continue to execute the operation after step (2), and replace can0 with vcan0 to process the replayed CAN data stream.

[0082] Finally, in this embodiment of the application, Rviz can be used to display visualized data. Rviz is a graphical tool that comes with ROS and can be used to perform graphical operations on ROS programs. The method of displaying visualized data output by the EyeQ4_ROS node using Rviz is as follows: (1) After the EyeQ4_ROS node program starts and runs normally, open a new command line and run Rviz; (2) Find and click "Add" in the lower left corner of the operation interface; (3) Find the "By topic" tab in the pop-up window, find the visualization topic created by EyeQ4 that needs to be displayed in the list and add it; (4) After adding the visualization topic, the Fixed Frame option under Global Option needs to be changed to "host". After adding all the optional visualization themes, the system interface displays the following: yellow, black, and white lines represent lane lines; gray lines represent road edges; blue lines represent lane centerline predictions; red dots represent stop line locations; green vehicles represent ordinary vehicle detection results; green cuboids represent truck detection results; and yellow cubes represent traffic light locations (traffic signs are not displayed). This allows for data processing based on ROS-based visual sensors, testing of path planning algorithms, and monitoring and visualization of vehicle status.

[0083] In summary, based on the specific discussion of the embodiments of this application above, the following beneficial effects can be achieved:

[0084] (1) The design of the three-layer class inheritance structure makes the responsibilities of each layer clear, which is easy to maintain and expand the data. It is also easy to port to non-ROS environments. It can also realize the distribution function of EyeQ4 output data, so that different data processing nodes can use the output messages at the same time. It also has a unified interface protocol, which ensures that the published ROS message structure is consistent with the original CAN output data of EyeQ4, and simplifies the data mapping and usage logic.

[0085] (2) By defining multiple ROS topics for publishing different types of data, such as object detection, lane line information, and road signs, the standardization and efficiency of data transmission are ensured;

[0086] (3) Through data management and testing, data collection and playback functions were designed to facilitate the algorithm development and testing phase, ensure the repeatability and efficiency of algorithm verification, and realize intuitive visualization of EyeQ4 output data, which helps relevant technical personnel to intuitively understand the data structure and accelerate the algorithm iteration and debugging process.

[0087] According to the ROS-based driver node software design method of this application, at least one CAN raw data is acquired. Based on the corresponding ID of each CAN raw data, a corresponding target decoding device is matched to decode the CAN raw data, resulting in decoded CAN data for each CAN raw data. The data category of each decoded CAN data is obtained, and a corresponding message topic is matched based on the data category to publish the corresponding decoded CAN data. This solves the problems of inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects in related technologies. By designing a three-layer class software inheritance structure, the efficiency and flexibility of ROS-based EyeQ4 data processing, as well as the convenience of algorithm development and testing, are improved.

[0088] Next, referring to the accompanying drawings, a ROS-based driver node software design apparatus is described according to an embodiment of this application.

[0089] Figure 4 This is a block diagram of a ROS-based driver node software design device according to an embodiment of this application.

[0090] like Figure 4 As shown, the ROS-based driver node software design device 10 includes: an acquisition module 100, a parsing module 200, and a matching module 300.

[0091] The acquisition module 100 is used to acquire at least one CAN raw data.

[0092] The parsing module 200 is used to match the target decoding device for each original data ID according to the corresponding ID of each original data, and to decode the corresponding original data according to the target decoding device for each original data ID, so as to obtain the decoded CAN data corresponding to each original data.

[0093] The matching module 300 is used to obtain the data category of each decoded CAN data, match the corresponding message topic according to the data category of each decoded CAN data, and publish the corresponding decoded CAN data according to the message topic.

[0094] According to one embodiment of this application, after matching the corresponding message topic based on the data category of each decoded CAN data, the matching module 300 further includes:

[0095] The first acquisition unit is used to acquire the ROS message library corresponding to the data category of each decoded CAN data.

[0096] The encapsulation unit is used to encapsulate each decoded CAN data into the corresponding ROS message library, and publish the ROS message library containing the decoded CAN data to the corresponding message topic.

[0097] According to one embodiment of this application, the packaging unit further includes:

[0098] The identification subunit is used to identify the target ROS message library for visualizing decoded CAN data encapsulated in all ROS message libraries.

[0099] The generation subunit is used to generate CAN image information based on the decoded CAN data in the target ROS message library, and publish the CAN image information to the corresponding visualization message topic.

[0100] According to one embodiment of this application, after obtaining the decoded CAN data corresponding to each raw CAN data, the parsing module 200 further includes:

[0101] The second acquisition unit is used to acquire CAN data subscription requests;

[0102] The determination unit is used to determine the topic of the message to be published based on the CAN data subscription requirements.

[0103] The filtering unit is used to filter out the target CAN data from all decoded CAN data based on the topic of the message to be published, and then publish the target CAN data.

[0104] According to one embodiment of this application, the target decoding device is a DBC protocol file.

[0105] According to the ROS-based driver node software design apparatus of this application embodiment, at least one CAN raw data is acquired. Based on the corresponding ID of each CAN raw data, a corresponding target decoding device is matched to decode the corresponding CAN raw data, resulting in decoded CAN data for each CAN raw data. The data category of each decoded CAN data is acquired, and a corresponding message topic is matched based on the data category of each decoded CAN data to publish the corresponding decoded CAN data. This solves the problems of inaccurate message parsing, low data distribution efficiency, cumbersome data collection and playback operations, and unsatisfactory data visualization effects in related technologies. By designing a three-layer class software inheritance structure, the efficiency and flexibility of ROS-based EyeQ4 data processing, as well as the convenience of algorithm development and testing, are improved.

[0106] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include:

[0107] The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0108] When the processor 502 executes the program, it implements the ROS-based driver node software design method provided in the above embodiments.

[0109] Furthermore, electronic devices also include:

[0110] Communication interface 503 is used for communication between memory 501 and processor 502.

[0111] The memory 501 is used to store computer programs that can run on the processor 502.

[0112] The memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0113] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0114] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0115] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0116] This embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described ROS-based driver node software design method.

[0117] This embodiment also provides a computer program product, including a computer program that is executed to implement the ROS-based driver node software design method of the above embodiments.

[0118] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0119] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0120] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0121] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0122] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0123] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments.

[0124] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0125] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A ROS-based driver node software design method, characterized in that, The method includes the following steps: Acquire at least one raw CAN data from the controller area network; The target decoding device for each raw CAN data ID is matched according to the corresponding identity ID of each raw CAN data, and the corresponding raw CAN data is decoded according to the target decoding device of each raw CAN data ID to obtain the decoded CAN data corresponding to each raw CAN data. Obtain the data category of each decoded CAN data, match the corresponding message topic according to the data category of each decoded CAN data, and publish the corresponding decoded CAN data according to the message topic.

2. The method according to claim 1, characterized in that, After matching the corresponding message topic according to the data category of each decoded CAN data, the process further includes: Obtain the robot operating system ROS message library corresponding to the data category of each decoded CAN data; Each decoded CAN data is encapsulated into its corresponding ROS message library, and the ROS message library containing the decoded CAN data is published to the corresponding message topic.

3. The method according to claim 2, characterized in that, The step of publishing the ROS message library containing the decoded CAN data to the corresponding message topic also includes: Identify the target ROS message library that encapsulates decoded CAN data into visualized data in all ROS message libraries; CAN image information is generated based on the decoded CAN data in the target ROS message library, and the CAN image information is published to the corresponding visualization message topic.

4. The method according to claim 1, characterized in that, After obtaining the decoded CAN data corresponding to each raw CAN data, the following is also included: Obtain CAN data subscription requirements; The topic of the message to be published is determined based on the CAN data subscription requirements; Based on the topic of the message to be published, the target CAN data is selected from all decoded CAN data and published.

5. The method according to claim 1, characterized in that, The target decoding device is a DBC protocol file.

6. A software design device for driver nodes based on ROS, characterized in that, include: The acquisition module is used to acquire at least one piece of raw CAN data. The parsing module is used to match the target decoding device for each original data ID according to the corresponding ID of each original data, and to decode the corresponding original data according to the target decoding device of each original data ID, so as to obtain the decoded CAN data corresponding to each original data. The matching module is used to obtain the data category of each decoded CAN data, match the corresponding message topic according to the data category of each decoded CAN data, and publish the corresponding decoded CAN data according to the message topic.

7. The apparatus according to claim 6, characterized in that, After matching the corresponding message topic according to the data category of each decoded CAN data, the matching module further includes: The acquisition unit is used to acquire the ROS message library corresponding to the data category of each decoded CAN data. The encapsulation unit is used to encapsulate each decoded CAN data into the corresponding ROS message library, and publish the ROS message library containing the decoded CAN data to the corresponding message topic.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the ROS-based driver node software design method as described in any one of claims 1-5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the ROS-based driver node software design method as described in any one of claims 1-5.

10. A computer program product, comprising a computer program, characterized in that, The computer program is executed to implement the ROS-based driver node software design method as described in any one of claims 1-5.

Images