Method and device for playing automatic driving data packet
By parallelizing the message generation and consumption process in the playback class of the autonomous driving data packets, and using multi-threaded management of the task buffer area, the problem of packet playback delay in the autonomous driving scenario is solved, and efficient and time-series packet playback is achieved.
Patent Information
- Application Number
- CN202411997609.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-31
- Publication Date
- 2025-05-06
AI Technical Summary
In autonomous driving scenarios, how to reduce the delay of data packets during playback has become an urgent problem.
By creating a message generation class and a message consumption class in the playback class of the recording and playback package tool, the first thread obtains message data and creates a task, and stores it in the task cache area. The second thread reads the task from the task cache area and determines the publishing time based on the timestamp of the message data, publishes message data through the publisher object, and clears the executed tasks.
It reduces processing delay, improves the response speed and overall efficiency of data packet playback, improves the efficiency of development and testing of autonomous driving scenarios, and ensures the timing of data playback.
Smart Images
Figure CN119938357A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of autonomous driving technology, and in particular to a method and device for playing an autonomous driving data packet. Background Art
[0002] In the development of autonomous driving software, in order to reduce the cost of actual road testing and improve debugging efficiency, developers often use tools to record the message data between vehicle modules and save them as files. During the playback of the recorded files, the tool controls the message publishing time according to the timestamp to simulate the message transmission in actual road testing.
[0003] However, when processing large amounts of data or high-frequency data, related technologies need to frequently read data from recorded files and determine the difference between the timestamp and the playback reference time. Insufficient processing power may lead to delays and data loss during playback. Therefore, in autonomous driving scenarios, how to reduce the delay of data packets during playback has become an urgent problem to be solved. Summary of the invention
[0004] In view of this, the present disclosure provides a method and device for playing an autonomous driving data packet to solve the problem of how to reduce the delay of the data packet during the playback process in an autonomous driving scenario.
[0005] On the one hand, the present disclosure provides a method for playing an autonomous driving data packet, the method comprising: creating a message generation class and a message consumption class in a playback class of a recording and broadcasting package tool; the playback class of the recording and broadcasting package tool is used to play the autonomous driving data packet; based on a first thread in the message generation class, message data is obtained in the autonomous driving data packet, a corresponding task is created based on the message data, and the task is stored in a task cache; the task includes the message data and a publisher object corresponding to the message data; based on a second thread in the message consumption class, the task is read from the task cache, and when the message data reaches the playback time according to the timestamp of the message data in the task, the message data is published through the publisher object, and the executed task is cleared.
[0006] The present disclosure also provides a device for playing an autonomous driving data packet, the device comprising: an initialization module for creating a message generation class and a message consumption class in a playback class of a recording and playback package tool;
[0007] The playback class of the package tool is used to play the autonomous driving data packet; the message determination module is used to obtain message data in the autonomous driving data packet based on the first thread in the message generation class, create corresponding tasks based on the message data, and store the tasks in the task cache; the tasks include message data and the publisher object corresponding to the message data; the message publishing module is used to read the task from the task cache based on the second thread in the message consumption class, determine when the message data arrives at the playback time according to the timestamp of the message data in the task, publish the message data through the publisher object, and clear the executed tasks.
[0008] On the other hand, the present disclosure further provides a computer device, which includes: a memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor implements the above-mentioned method for playing the autonomous driving data packet by executing the computer instructions.
[0009] On the other hand, the present disclosure further provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to enable a computer to implement the above-mentioned method for playing the autonomous driving data packet.
[0010] Through the method and device for playing the autonomous driving data packet of the above-mentioned embodiment of the present invention, the message generation and consumption processes are parallelized by using the first thread in the message generation class and the second thread in the message consumption class, thereby reducing processing delays, improving the response speed and overall efficiency of data packet playback, and improving the efficiency of development and testing of autonomous driving scenarios.
[0011] In addition, according to the relationship between the timestamp of the message data and the playback time, the release time of the message is accurately controlled to ensure the timing of data playback and simulate the actual data transmission situation in actual road tests. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the related technologies, the drawings required for use in the specific embodiments or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0013] Figure 1 is a flowchart of a method for playing an autonomous driving data packet provided by an embodiment of the present disclosure;
[0014] Figure 2 It is a specific flow chart of a method for playing an autonomous driving data packet provided by an embodiment of the present disclosure;
[0015] Figure 3 This is a schematic diagram of a first thread execution flow of a method for playing an autonomous driving data packet provided by an embodiment of the present disclosure;
[0016] Figure 4 It is a schematic diagram of a second thread execution flow of a method for playing an autonomous driving data packet provided by an embodiment of the present disclosure;
[0017] Figure 5 is a structural schematic diagram of a device for playing an autonomous driving data packet provided in an embodiment of the present disclosure;
[0018] Figure 6 It is a structural schematic diagram of another device for playing an autonomous driving data packet provided in an embodiment of the present disclosure. DETAILED DESCRIPTION
[0019] In the process of developing autonomous driving software, due to the high cost of actual road testing and the difficult debugging process, developers often need a tool to simulate data transmission in the road test environment so as to debug the vehicle software in a non-actual road test environment. To this end, developers use the broadcast and recording package tool to record the communication messages between various modules in the vehicle operation and store these messages as files. The tool saves these messages and their timestamps to files by subscribing to channel messages published by different nodes. In the subsequent debugging process, developers read the data packets in the file and publish the recorded channels and messages to simulate the message transmission during the actual road test.
[0020] When playing messages, the tool will control the moment of message release according to the timestamp and reference time stored in the file to ensure that the order of message release is the same as in the actual drive test. Specifically, the playback class will create the corresponding publisher and publish the message to the corresponding channel, controlling the playback time of the message so that the debugging process can truly reflect the message transmission in the actual drive test.
[0021] However, when the amount of data to be played is large (such as high-definition images or point cloud data) and the frequency of the data is high, the relevant technologies often have the following problems:
[0022] 1. Due to frequent reading of data from files and determining the difference between the timestamp and the playback reference time, insufficient processing power may cause delays or data loss during playback;
[0023] 2. When the time consumed to read messages is greater than the interval between messages, the system may not be able to play messages at the actual speed, resulting in the data not being able to truly reflect the actual situation;
[0024] 3. In the case of high-frequency data transmission, the processing speed of existing tools cannot keep up with the data playback speed, affecting the accuracy and effectiveness of debugging.
[0025] To solve the above problems, various embodiments of the present invention provide a method for playing an autonomous driving data packet, the method comprising: creating a message generation class and a message consumption class in the playback class of a recording and broadcasting package tool; the playback class of the recording and broadcasting package tool is used to play the autonomous driving data packet; based on the first thread in the message generation class, message data is obtained in the autonomous driving data packet, a corresponding task is created based on the message data, and the task is stored in a task cache; the task includes the message data and a publisher object corresponding to the message data; based on the second thread in the message consumption class, the task is read from the task cache, and when the message data reaches the playback time according to the timestamp of the message data in the task, the message data is published through the publisher object, and the executed tasks are cleared.
[0026] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present disclosure.
[0027] Please refer to Figure 1 , Figure 1 : is a flow chart of a method for playing an autonomous driving data packet provided by an embodiment of the present disclosure. The flow of the method may include the following steps:
[0028] Step S101, creating a message generation class and a message consumption class in the playback class of the recording and broadcasting package tool.
[0029] In this embodiment, the playback class of the recording and broadcasting package tool is used to play the autonomous driving data packet. Among them, the recording and broadcasting package tool may refer to a tool for autonomous driving software development and debugging, which can record and replay messages transmitted between modules through the publish-subscribe mechanism during vehicle operation. Specifically, the recording and broadcasting package tool can subscribe to channel messages of different nodes in actual road tests, and save these message data and their timestamps to files. It can also read the recorded files during the development and debugging stage, and republish the messages according to the recorded timestamps and channel information, simulating the data transmission in actual scenarios, and helping developers verify the functions and performance of each module of the system.
[0030] Among them, the file can be used to store various data generated in road testing and / or simulation in the autonomous driving system; the autonomous driving data packet (also called a recording packet or data packet) is stored in the file, and the autonomous driving data packet can include at least one kind of message data.
[0031] As an example, the autonomous driving data packet may include at least one of the following message data: sensor data, vehicle status data, message communication records, etc. The above message data can be played back during the development and debugging process.
[0032] Furthermore, the playback class of the recording and playback package tool can be responsible for implementing the playback function of the autonomous driving data packet.
[0033] In a possible implementation of the above embodiment, creating a message generation class and a message consumption class in the playback class of the recording and broadcasting package tool may include:
[0034] Create a message generation class and a message consumption class in the initialization function of the playback class of the recording and playback package tool.
[0035] The message generation class may refer to a component in the recording and broadcasting package tool that is used to read message data and generate tasks, and the message consumption class may refer to a component in the recording and broadcasting package tool that is used to read tasks and publish messages.
[0036] Here, the message generation class and the message consumption class can be responsible for the reading, processing and scheduling of message data respectively, and together they can realize the efficient playback function of the recorded broadcast package for the autonomous driving data packet.
[0037] Step S102, based on the first thread in the message generation class, obtain message data in the autonomous driving data packet, create a corresponding task based on the message data, and store the task in the task cache area.
[0038] In this embodiment, the task includes message data and a publisher object corresponding to the message data. Among them, the task (i.e., task) can be a data structure used to carry the message data in the autonomous driving data packet and its associated publisher object (i.e., publisher). The publisher object can be an entity associated with a message channel, used to send message data to other subscribers.
[0039] Here, the message data may be an information unit obtained from the autonomous driving data packet, and the message data may include but is not limited to sensor data, control instructions, inter-module communication data, timestamps, etc. Each message data corresponds to a timestamp, which is used to indicate the sending time of the message data in the actual scenario, so as to simulate the real release scenario.
[0040] Based on the first thread in the message generation class, it can include: in the start function of the playback class of the recording and broadcasting package tool, calling the method of the message generation class to create and start the first thread; wherein the first thread is used to represent the operation execution carrier of the message generation class to ensure that the acquisition of message data and the generation of tasks are performed independently of the main thread.
[0041] Obtaining message data in an autonomous driving data packet may include: obtaining data content, a timestamp, and a channel list in the autonomous driving data packet, and determining a message channel corresponding to the data content in the channel list.
[0042] Creating a corresponding task based on the message data may include: encapsulating the message data and the corresponding publisher object into a task data structure.
[0043] The task cache area can be a shared data structure in the recording package tool for storing tasks generated by the message generation class and for consumption by the message consumption class. For example, the task cache area can be a thread-safe queue or buffer.
[0044] Step S103, based on the second thread in the message consumption class, read the task from the task cache, determine when the message data reaches the playback time according to the timestamp of the message data in the task, publish the message data through the publisher object, and clear the executed task.
[0045] In this embodiment, the play time may be a specific time point when the message data in the task should be released, and may be specifically set according to requirements.
[0046] Based on the second thread in the message consumption class, it can include: in the start function of the playback class of the recording package tool, calling the method of the message consumption class to create and start the second thread; wherein the second thread is used to represent the operation execution carrier of the message consumption class to ensure that the acquisition of message tasks and the release of messages are performed independently of the main thread.
[0047] Here, in the start function of the play class of the recording and broadcasting package tool, the second thread and the first thread may be run in parallel.
[0048] Reading the task from the task buffer may include: the second thread accessing the task buffer through a lock mechanism, and reading the task from the queue in the order in which the task arrives;
[0049] After the second thread reads the task, it releases the lock of the task buffer area for access by other threads.
[0050] In a possible implementation of the above embodiment, when the task buffer is empty, the second thread is put into a waiting state and periodically checks the buffer state to wait for a new task to enter.
[0051] Clearing the executed tasks may include: after the message data has been published through the publisher object, based on the second thread, clearing the tasks corresponding to the message data in the task cache area to ensure that the tasks in the task cache area are all tasks to be executed.
[0052] In the method and device for playing the autonomous driving data packet of the above-mentioned embodiment of the present disclosure, by using the first thread in the message generation class and the second thread in the message consumption class, the message generation and consumption processes are parallelized, thereby reducing processing delays, improving the response speed and overall efficiency of data packet playback, and improving the efficiency of development and testing of autonomous driving scenarios. According to the relationship between the timestamp and the playback time of the message data, the release time of the message is accurately controlled to ensure the timing of data playback, and can simulate the actual data transmission situation in the actual road test. The task cache area is used to support the streaming processing of high-frequency data through the queue mechanism, which can effectively alleviate the backlog problem in the case of high data volume, and at the same time enable the second thread to dynamically adjust the release rhythm according to the timestamp, reduce the risk of frame loss and data lag, and ensure the real-time release capability of high-frequency messages.
[0053] In a possible implementation of the above step S101, a message generation class and a message consumption class are created in the playback class of the recording and broadcasting package tool, including:
[0054] Create a message generation class and a message consumption class in the initialization function of the playback class of the recording and playback package tool;
[0055] Based on the message generation class, create a file reader, which is used to read the message data of the autonomous driving data packet in the file;
[0056] Based on the message generation class, the playback option parameters are set during the initialization of the playback class. The playback option parameters are used to determine the playback strategy of the autonomous driving data packet.
[0057] Based on the message generation class, a corresponding publisher object is created for at least one message channel in the autonomous driving data packet, and the publisher object corresponding to each message channel is stored in a preset publisher lookup table in the form of a key-value pair.
[0058] In this embodiment, a file reader is created based on a message generation class. The file reader is used to read the message data of the autonomous driving data packet in the file. The method may include: during the initialization process of the message generation class, the basic configuration information of the file reader is preset, a file reader object is instantiated in the message generation class, the interface of the file reader object is called, and the message data is read one by one from the file.
[0059] The message data read from the file by the file reader (ie, recordreader) object may include at least one of the following: message ID, timestamp, message type, message channel, message priority, message size, and message data content.
[0060] The playback option parameter may be a configuration item for controlling the playback behavior of the recording and broadcasting package tool. The playback option parameter may include, but is not limited to: whether to loop, whether to delay, whether to adjust the speed, whether to filter messages, etc.
[0061] An autonomous driving data packet may contain multiple message channels, each of which may be associated with a specific sensor type or system module, and data from different sensor types or system modules will be published to the corresponding message channel. For example, message channels may include but are not limited to: camera channel, inertial measurement unit channel, etc.
[0062] Based on the message generation class, a corresponding publisher object is created for at least one message channel in the autonomous driving data packet, which may include:
[0063] For each message channel in the autonomous driving data packet, a corresponding publisher object is created for each message channel based on the message generation class, so as to use the publisher object to publish the message data in the message channel to the corresponding class.
[0064] The publisher object corresponding to each message channel is stored in the preset publisher lookup table in the form of key-value pairs, which may include:
[0065] Based on the message generation class, when a new publisher object is created, the publisher object is stored in the preset publisher lookup table pub_map in the form of a key-value pair.
[0066] Among them, pub_map can be an unordered_map<std::string,Publisher*> A container of type, channelName can be the channel name, and publisher can be the corresponding publisher object.
[0067] Here, by presetting the publisher lookup table pub_map to store message channels and corresponding publisher objects, publishers of different channels can be dynamically managed to ensure accurate data delivery, and the mapping relationship between message channels and publisher objects can be centrally managed.
[0068] In the method and device for playing the autonomous driving data packet of the above-mentioned embodiment of the present disclosure, by clearly dividing the processes such as message generation, file reading, and message publishing, the recording and broadcasting package tool can efficiently process the messages in the autonomous driving data packet. By setting the playback option parameters, the user can flexibly control the playback strategy, thereby more accurately simulating the actual road test situation and improving the simulation effect. The publisher object is stored in the preset publisher search table to ensure the rapid search and accurate publishing of messages.
[0069] In a possible implementation of the above step S102, based on the first thread in the message generation class, message data is obtained in the autonomous driving data packet, a corresponding task is created based on the message data, and the task is stored in the task cache area, which is implemented based on the following steps:
[0070] Execute the start function of the playback class of the recording and broadcasting package tool, and use the start function to create a first thread in the message generation class; the first thread is used to represent the operation execution carrier of the message generation class;
[0071] Based on the first thread, obtain message data in the autonomous driving data packet from the file reader;
[0072] When the amount of message data is less than the preset number of messages, a task is created based on the message data, and the task is stored in the task buffer.
[0073] In this embodiment, the function of the start function may be to start the playing process and execute the first thread. Here, the start function may call the initialization function of the message generation class to create the first thread.
[0074] Based on the first thread, obtaining message data in the autonomous driving data packet from the file reader may include: the first thread calls the file reader to load the stored autonomous driving data packet and reads the message data in sequence.
[0075] When the amount of message data is less than the preset number of messages, creating a task based on the message data and storing the task in the task buffer may include:
[0076] Each time the first thread reads a message data, it checks whether the number of messages currently read has reached the preset number of messages. When the current number of messages is less than the preset number of messages, the first thread continues to run.
[0077] Here, when the first thread reads a message data each time, it creates a corresponding task based on the read message data, and stores the created tasks in the task buffer in order. The preset number of messages can be pre-stored in the message generation class, and can be specifically set according to actual needs, which is not limited here.
[0078] Furthermore, the first thread continues to run until the number of tasks in the task cache is greater than the preset number of messages, at which point the first thread is stopped. The fact that the number of tasks in the task cache is greater than the preset number of messages indicates that the current first thread has too much data to process, which may cause a performance bottleneck or affect the execution of other threads.
[0079] In a possible implementation of the above embodiment, the method also includes: during the running process of the first thread in the message generation class, when the number of acquired message data is greater than the preset number of messages, the first thread gives up CPU resources by thread hibernation and allocates CPU resources to other threads.
[0080] In this embodiment, when the amount of acquired message data (that is, the number of tasks in the task cache) is greater than the preset number of messages, the first thread can be put to sleep to release central processing unit (CPU) resources and allocate CPU resources to other threads.
[0081] Here, when the first thread goes into sleep, the second thread starts running, reading tasks and sending message data.
[0082] Furthermore, when the second thread runs to the point where the amount of message data is again less than the preset number of messages, the first thread is called up to continue to execute the tasks of obtaining message data from the file reader and creating the task.
[0083] In the method and device for playing an autonomous driving data packet in the above-mentioned embodiment of the present disclosure, when the number of message data is greater than the preset number of messages, the first thread releases CPU resources by sleeping, avoids excessive CPU occupation, and ensures that the system can efficiently utilize multi-threaded parallel processing. Through the sleep mechanism, the first thread can give up the CPU when the amount of data is too large, and the second thread can continue to execute when the first thread is sleeping, thereby realizing parallel processing of message data. This parallel processing can effectively improve the throughput during data packet playback and avoid bottlenecks caused by excessive load on a single thread. By setting a reasonable number of preset messages, the workload of each thread can be dynamically adjusted, and the execution of the thread can be flexibly controlled according to the current amount of message data and the allocation of CPU resources, thereby improving the stability and response speed of data packet playback.
[0084] In a possible implementation of the above step S103, based on the second thread in the message consumer class, the task is read from the task cache, and when the message data reaches the playback time according to the timestamp of the message data in the task, the message data is published through the publisher object, and the executed task is cleared, which is implemented based on the following steps:
[0085] A start function is used to create a second thread in the message consumer class; the second thread is used to represent the operation execution carrier of the message consumer class;
[0086] Based on the second thread, the message data in the task is read in the task buffer area, and whether the message data reaches the playback time is determined according to the timestamp in the message data and the playback reference time;
[0087] When it is determined that the message data reaches the playback time, the publisher object corresponding to the message data is determined in the preset publisher lookup table, the message data is published through the preset publishing function of the publisher object, and the executed tasks are cleared.
[0088] In this embodiment, the function of the start function can also be to start the playing process and execute the second thread. Here, the start function can call the initialization function of the message generation class to create the second thread.
[0089] The playback reference time can be represented as the timestamp of the first message played.
[0090] In a possible implementation of the above embodiment, determining whether the message data has reached the playback time according to the timestamp in the message data and the playback reference time may include:
[0091] Determine the time difference between the timestamp in the message data and the playback reference time, divide the time difference by the playback rate, and determine the estimated time difference;
[0092] When the estimated time difference is greater than the actual time difference, it is determined that the message data has not yet reached the playback time;
[0093] When the estimated time difference is less than or equal to the actual time difference, it is determined that the message data arrives at the playback time.
[0094] In this embodiment, the timestamp msg_play_time_ns of the message data to be played and the base playing time base_play_time_ns are determined, and the time difference between msg_play_time_ns and base_play_time_ns is divided by the playing rate play_rate to obtain the estimated time difference as shown below:
[0095] task_interval_ns=(msg_play_time_ns-base_play_time_ns) / play_rate
[0096] Among them, base_play_time_ns represents the timestamp corresponding to the first message waiting to be played, that is, the scheduled playing time of the first message in the data packet, which is the timestamp of the message data itself.
[0097] Furthermore, the real time difference real_time_interval_ns may refer to the time difference between the current clock moment current_time of program execution and the clock moment base_real_time_ns when the program plays the first message, wherein base_real_time_ns represents the actual time when the system actually starts to process the data packet and plays the first message.
[0098] That is, the actual time difference can be expressed by the formula real_time_interval_ns=current_time-base_real_time_ns.
[0099] When the expected time difference task_interval_ns is greater than the actual time difference real_time_interval_ns, it is determined that the message data has not arrived at the playback time. When the expected time difference task_interval_ns is less than or equal to the actual time difference real_time_interval_ns, it is determined that the message data has arrived at the playback time.
[0100] The expected time difference task_interval_ns can be the time interval from the generation of a task to the expected playback. It is calculated based on the timestamp of the task and the reference time, indicating the difference between the time when the task should be executed theoretically and the reference time. The actual time difference real_time_interval_ns is the actual time difference between the current time and the reference time.
[0101] When the expected time difference task_interval_ns is greater than the actual time difference real_time_interval_ns, it means that the expected execution time of the task has not yet arrived. At this time, the message has not yet reached the scheduled playback time, so the message should not be released, so that the second thread continues to wait. When the expected time difference task_interval_ns is less than or equal to the actual time difference real_time_interval_ns, it means that the expected execution time of the task has arrived or has passed, and the second thread believes that the message has reached the scheduled playback time and can release the message.
[0102] In a possible implementation of the above embodiment, the method also includes: when the expected time difference is greater than the actual time difference, determining the time difference between the expected time difference and the actual time difference, and after waiting for the time difference, publishing the message data through the preset publishing function of the publisher object to clear the executed tasks.
[0103] In this embodiment, when the expected time difference task_interval_ns is greater than the actual time difference real_time_interval_ns, the time difference is calculated using the following formula:
[0104] sleep_ns=task_interval_ns-real_time_interval_ns
[0105] The second thread is made to wait for the time difference sleep_ns before playing the message data.
[0106] In the method and device for playing the autonomous driving data packet of the above-mentioned embodiment of the present disclosure, according to the timestamp and playback reference time of the message data, the estimated time difference and the actual time difference are calculated to determine whether the message has reached the playback time. Through this precise control, it can be ensured that the message data is played at a predetermined playback rate, thereby ensuring the synchronization and accuracy of the message data. When the estimated time difference is greater than the actual time difference, the difference between the two is calculated to make the second thread sleep for a corresponding time, release CPU resources, and avoid meaningless busy waiting of the second thread. This method reduces the burden on the CPU through thread sleep and improves the overall performance of the system.
[0107] In a specific embodiment, please refer to Figure 2 , Figure 2 : is a schematic diagram of a specific process of a method for playing an autonomous driving data packet provided by an embodiment of the present disclosure. The specific process may include the following steps:
[0108] Step S201, start the recording package tool;
[0109] Step S202, calling the initialization function of the playback class;
[0110] Here, create the message generation class and message consumption class in the initialization function;
[0111] Specifically, the following steps are included:
[0112] Step S2021, creating a file reader for each file;
[0113] Here, based on the message generation class, a file reader is created for each file, and the file reader is used to read the message data of the autonomous driving data packet in the file;
[0114] Step S2022, setting playback option parameters;
[0115] Here, based on the message generation class, the playback option parameters are set during the initialization process of the playback class, and the playback option parameters are used to determine the playback strategy of the autonomous driving data packet;
[0116] Step S2023, creating a publisher object for each message channel in the file, and updating the publisher object to a preset publisher lookup table;
[0117] Here, based on the message generation class, a corresponding publisher object is created for at least one message channel in the autonomous driving data packet, and the publisher object corresponding to each message channel is stored in a preset publisher lookup table in the form of a key-value pair;
[0118] Step S203, calling the start function of the play class;
[0119] Here, the start function of the playback class of the recording and broadcasting package tool is executed, and the start function is used to create a first thread in the message generation class and a second thread in the message consumption class;
[0120] Specifically, the following steps are included:
[0121] Step S2031, read the message data, create a task, and update the task to the task cache;
[0122] Here, based on the first thread in the message generation class, the message data is obtained in the autonomous driving data packet, a corresponding task is created based on the message data, and the task is stored in the task cache area;
[0123] Step S2032, using the publisher object in the preset publisher search table to publish the message data in the task;
[0124] Here, when it is determined that the message data has reached the playback time, the publisher object corresponding to the message data is determined in the preset publisher lookup table, the message data is published through the preset publishing function of the publisher object, and the executed tasks are cleared;
[0125] Step S2033, detecting whether there is keyboard input, if yes, pausing the playback;
[0126] Here, the second thread detects whether there is keyboard input, and if so, pauses the playback.
[0127] In a specific embodiment, please refer to Figure 3 , Figure 3 1 is a schematic diagram of a first thread execution flow of a method for playing an autonomous driving data packet provided by an embodiment of the present disclosure. The flow may include the following steps:
[0128] Step S301, creating a first thread;
[0129] Step S302, looping to read message data from the file reader;
[0130] Here, based on the first thread, a file reader is created for each file, and the file reader is used to read message data from the file;
[0131] Step S303, determine whether the number of message data is less than the preset number of messages, if so, proceed to step S304, if not, proceed to step S305;
[0132] Step S304, convert the message data into a task, store it in the task buffer area, and wait for reading;
[0133] Here, when the number of message data is less than the preset number of messages, based on the first thread, a task is created according to the message data and the corresponding publisher object, and the task is stored in the task cache area;
[0134] Step S305, making the first thread sleep, the second thread reads the task, and returns to step S303;
[0135] Here, when the number of message data is greater than the preset number of messages, the first thread is put into sleep mode, the CPU resources are released, and the second thread reads the tasks in the task buffer.
[0136] In a specific embodiment, please refer to Figure 4 , Figure 4 1 is a schematic diagram of a second thread execution flow of a method for playing an autonomous driving data packet provided by an embodiment of the present disclosure. The flow may include the following steps:
[0137] Step S401, creating a second thread;
[0138] Step S402, cyclically reading tasks from the task buffer;
[0139] Step S403, determine whether the estimated time difference is greater than the actual time difference, if so, proceed to step S404, if not, proceed to step S405;
[0140] Here, the time difference between the timestamp in the message data and the playback reference time is determined, the time difference is divided by the playback rate to determine the estimated time difference, and the actual time difference is determined to be the time difference between the current time and the playback reference time;
[0141] Step S404, the second thread waits for the time difference and then publishes the message data;
[0142] Here, the time difference is the difference between the expected time difference and the actual time difference;
[0143] Step S405, publishing the message data according to the publisher object in the task;
[0144] Here, based on the second thread, the publisher function provided by the publisher object is used to publish the message data contained in the task.
[0145] Figure 5 is a schematic diagram of the structure of a playback device for an autonomous driving data packet provided by an embodiment of the present disclosure, such as Figure 5 As shown, the device can be applied to intelligent electronic devices such as servers and computers; the device includes: an initialization module 501, a message determination module 502 and a message publishing module 503; wherein,
[0146] Initialization module 501, used to create a message generation class and a message consumption class in the playback class of the recording and broadcasting package tool; the playback class of the recording and broadcasting package tool is used to play the autonomous driving data packet;
[0147] The message determination module 502 is used to obtain message data in the autonomous driving data packet based on the first thread in the message generation class, create a corresponding task based on the message data, and store the task in the task cache area; the task includes the message data and the publisher object corresponding to the message data;
[0148] The message publishing module 503 is used to read the task from the task cache based on the second thread in the message consumption class, determine when the message data reaches the playback time according to the timestamp of the message data in the task, publish the message data through the publisher object, and clear the executed task.
[0149] In a specific embodiment, the initialization module 501 is used to create a message generation class and a message consumption class in the initialization function of the playback class of the recording and broadcasting package tool;
[0150] Based on the message generation class, create a file reader, which is used to read the message data of the autonomous driving data packet in the file;
[0151] Based on the message generation class, the playback option parameters are set during the initialization of the playback class. The playback option parameters are used to determine the playback strategy of the autonomous driving data packet.
[0152] Based on the message generation class, a corresponding publisher object is created for at least one message channel in the autonomous driving data packet, and the publisher object corresponding to each message channel is stored in a preset publisher lookup table in the form of a key-value pair.
[0153] In a specific embodiment, the message determination module 502 is used to execute the start function of the playback class of the recording and broadcasting package tool, and use the start function to create a first thread in the message generation class; the first thread is used to represent the operation execution carrier of the message generation class;
[0154] Based on the first thread, obtain message data in the autonomous driving data packet from the file reader;
[0155] When the amount of message data is less than the preset number of messages, a task is created based on the message data, and the task is stored in the task buffer.
[0156] In a specific embodiment, the apparatus further includes: a first dormancy module 504, wherein:
[0157] The first dormancy module 504 is used to make the first thread in the message generation class give up CPU resources by thread dormancy and allocate CPU resources to other threads when the number of acquired message data is greater than the preset number of messages during the running process of the first thread in the message generation class.
[0158] In a specific embodiment, the message publishing module 503 is used to create a second thread in the message consumption class using a start function; the second thread is used to represent the operation execution carrier of the message consumption class;
[0159] Based on the second thread, the message data in the task is read in the task buffer area, and whether the message data reaches the playback time is determined according to the timestamp in the message data and the playback reference time;
[0160] When it is determined that the message data reaches the playback time, the publisher object corresponding to the message data is determined in the preset publisher lookup table, the message data is published through the preset publishing function of the publisher object, and the executed tasks are cleared.
[0161] In a specific embodiment, the message publishing module 503 is used to determine the time difference between the timestamp in the message data and the playback reference time, and divide the time difference by the playback rate to determine the estimated time difference;
[0162] When the estimated time difference is greater than the actual time difference, it is determined that the message data has not yet reached the playback time;
[0163] When the estimated time difference is less than or equal to the actual time difference, it is determined that the message data arrives at the playback time.
[0164] In a specific embodiment, the device further includes: a second dormancy module 505, wherein:
[0165] The second dormancy module 505 is used to determine the time difference between the expected time difference and the actual time difference when the expected time difference is greater than the actual time difference, and after waiting for the time difference, publish the message data through the preset publishing function of the publisher object to clear the executed tasks.
[0166] It should be noted that: the apparatus for playing the autonomous driving data packet provided in the above embodiment only uses the division of the above program modules as an example when implementing the corresponding method for playing the autonomous driving data packet. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the apparatus can be divided into different program modules to complete all or part of the above-described processing. Figure 1 The embodiments of the method shown belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.
[0167] The present disclosure also provides a computer device having the above Figure 5 A playback device for the autonomous driving data packet shown.
[0168] See also Figure 6 , Figure 6 is a structural diagram of another visual custom modeling device provided by an embodiment of the present disclosure, such as Figure 6 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 6 A processor 10 is taken as an example.
[0169] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.
[0170] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.
[0171] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0172] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.
[0173] The computer device also includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 may be connected via a bus or other means. Figure 6 The example of connecting through bus is taken in the following.
[0174] The input device 30 can receive input digital or character information, and generate key signal input related to the user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator bar, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (e.g., an LED) and a tactile feedback device (e.g., a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display and a plasma display. In some optional embodiments, the display device can be a touch screen.
[0175] The computer device also includes a communication interface, which is used for the computer device to communicate with other devices or a communication network.
[0176] The embodiments of the present disclosure also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present disclosure can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium and downloaded through a network, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.
[0177] A part of the present disclosure may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present disclosure through the operation of the computer. Those skilled in the art should understand that the existence of computer program instructions in computer-readable media includes, but is not limited to, source files, executable files, installation package files, etc., and accordingly, the way in which computer program instructions are executed by a computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to the computer.
[0178] Although the embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations are all within the scope defined by the appended claims.
Claims
1. A method for playing an automatic driving data packet, characterized in that: The method comprises: Create a message generation class and a message consumption class in the playback class of the recording and broadcasting package tool; the playback class of the recording and broadcasting package tool is used to play the autonomous driving data packet; Based on the first thread in the message generation class, message data is obtained in the autonomous driving data packet, a corresponding task is created based on the message data, and the task is stored in a task cache; the task includes the message data and a publisher object corresponding to the message data; Based on the second thread in the message consumption class, the task is read from the task cache area, and when the message data reaches the playback time according to the timestamp of the message data in the task, the message data is published through the publisher object, and the executed task is cleared.
2. The method according to claim 1, characterized in that The step of creating a message generation class and a message consumption class in the playback class of the recording and broadcasting package tool includes: Create a message generation class and a message consumption class in the initialization function of the playback class of the recording and playback package tool; Based on the message generation class, create a file reader, wherein the file reader is used to read the message data of the autonomous driving data packet in the file; Based on the message generation class, setting a playback option parameter during the initialization process of the playback class, wherein the playback option parameter is used to determine a playback strategy for the autonomous driving data packet; Based on the message generation class, a corresponding publisher object is created for at least one message channel in the autonomous driving data packet, and the publisher object corresponding to each message channel is stored in a preset publisher lookup table in the form of a key-value pair.
3. The method according to claim 2, characterized in that Based on the first thread in the message generation class, message data is obtained in the autonomous driving data packet, a corresponding task is created based on the message data, and the task is stored in the task cache area, which is implemented based on the following steps: Execute the start function of the playback class of the recording and broadcasting package tool, and use the start function to create a first thread in the message generation class; the first thread is used to represent the operation execution carrier of the message generation class; Based on the first thread, obtain message data in the autonomous driving data packet from the file reader; In the case that the amount of the message data is less than the preset message amount, a task is created based on the message data, and the task is stored in a task buffer area.
4. The method according to claim 3, characterized in that The method further comprises: During the operation of the first thread in the message generation class, when the amount of acquired message data is greater than the preset number of messages, the first thread is made to give up CPU resources by thread hibernation, and the CPU resources are allocated to other threads.
5. The method according to claim 4, characterized in that Based on the second thread in the message consumption class, the task is read from the task cache area, and when the message data reaches the playback time according to the timestamp of the message data in the task, the message data is published through the publisher object, and the executed task is cleared, which is implemented based on the following steps: Using the start function, a second thread is created in the message consumption class; the second thread is used to represent the operation execution carrier of the message consumption class; Based on the second thread, the message data in the task is read in the task buffer area, and according to the timestamp in the message data and the playback reference time, it is determined whether the message data reaches the playback time; When it is determined that the message data has reached the playback time, the publisher object corresponding to the message data is determined in a preset publisher lookup table, the message data is published through a preset publishing function of the publisher object, and the executed task is cleared.
6. The method according to claim 5, characterized in that The determining, based on the timestamp in the message data and the playback reference time, whether the message data has reached the playback time includes: Determine the time difference between the timestamp in the message data and the playback reference time, and divide the time difference by the playback rate to determine the estimated time difference; When the estimated time difference is greater than the actual time difference, determining that the message data has not yet reached the playing time; When the estimated time difference is less than or equal to the actual time difference, it is determined that the message data has arrived at the playing time.
7. The method according to claim 6, characterized in that The method further comprises: When the expected time difference is greater than the actual time difference, the time difference between the expected time difference and the actual time difference is determined, and after waiting for the time difference, the message data is published through the preset publishing function of the publisher object to clear the executed tasks.
8. A device for playing an automatic driving data packet, characterized in that: The device comprises: An initialization module, used to create a message generation class and a message consumption class in a playback class of a recording and broadcasting package tool; the playback class of the recording and broadcasting package tool is used to play the autonomous driving data packet; a message determination module, configured to obtain message data in the autonomous driving data packet based on the first thread in the message generation class, create a corresponding task based on the message data, and store the task in a task cache; the task includes the message data and a publisher object corresponding to the message data; A message publishing module is used to read the task from the task cache area based on the second thread in the message consumption class, determine when the message data arrives at the playback time according to the timestamp of the message data in the task, publish the message data through the publisher object, and clear the executed task.
9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method for playing the autonomous driving data packet according to any one of claims 1 to 7 by executing the computer instructions.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method for playing the autonomous driving data packet according to any one of claims 1 to 7.