Road data transmission method, device and equipment

Abstract

The application relates to the field of automobile electronics, in particular to a road data transmission method, device and equipment. A road data transmission method comprises the following steps: based on a starting position and a destination position of a vehicle in map data, a planning path is generated through the map data; according to a current position of the vehicle, road data of a first predetermined distance in front of the vehicle in the planning path is acquired multiple times; the road data acquired each time is encapsulated into a target data packet; and the target data packet is sent to a domain controller. Through a sliding window mechanism, only a minimum data set required by the vehicle in real time, i.e. data in a specific range in front of the vehicle at a certain moment, is transmitted, network load is greatly reduced, and extremely low delay and ultra-high real-time performance of information are ensured.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, and in particular to a method, apparatus and device for road data transmission. Background Technology

[0002] Intelligent driving in vehicles relies on the acquisition of map data. Maps often contain massive amounts of driving information, such as lane lines, gradients, curvature, and speed limits. Classic in-vehicle networks, such as Controller Area Network (CAN) or Controller Area Network with Flexible Data Rate (CAN-FD), have limited single-frame transmission capabilities and cannot directly transmit complete map data packets. Therefore, high-performance protocols such as in-vehicle Ethernet or SOME / IP are often required for map data transmission, which is costly. Summary of the Invention

[0003] This invention provides a road data transmission method, apparatus, and device to address the problems of limited transmission capacity and high transmission cost when vehicles transmit map data in the prior art.

[0004] In a first aspect, embodiments of the present invention provide a road data transmission method, the method comprising: Based on the vehicle's starting and destination locations in the map data, a planned route is generated using the map data. Based on the vehicle's current location, road data for the first predetermined distance ahead of the vehicle in the planned path is obtained multiple times; Each time the road data is acquired, it is encapsulated into a target data packet; The target data packet is sent to the domain controller.

[0005] Optionally, the step of repeatedly acquiring road data for a first predetermined distance ahead of the vehicle in the planned path based on the vehicle's current location includes: When the vehicle's current position is the starting position, the road within a first predetermined distance in front of the starting position in the map data is determined as the path window; Obtain the road data for each road within the path window.

[0006] Optionally, after obtaining the road data of each road within the path window, the method further includes: Continuously acquire vehicle location change information; Whenever the vehicle's position changes to a second predetermined distance in the planned path, the road within the second predetermined distance in front of the end point of the path window is added to the path window. Update the road data of each road within the path window; Specifically, when the vehicle's position changes by a second predetermined distance in the planned path, and the remaining third distance of the planned path is less than the second predetermined distance, the road at the third distance ahead of the end point of the path window is added to the path window.

[0007] Optionally, the step of encapsulating the acquired road data into a target data packet each time includes: The road data is encapsulated into a start frame, at least one data frame, and an end frame.

[0008] Optional, including: The start frame is used to announce the start of data push and to represent the number of road data to be sent in this target data packet, as well as the starting point of the path window; The data frame is used to characterize the attribute type information of road data, the location where the attribute type begins to take effect, and the distance covered by the attribute type. The attribute type information includes at least road speed limit, road gradient, road curvature, number of lanes, and road type. The end frame is used to indicate the end of the push of this target data packet.

[0009] Optionally, after sending the target data packet to the domain controller, the method further includes: Receive a response frame sent by the domain controller, the response frame being used to indicate that the domain controller has received the target data packet; When the response frame is received, it is determined that the transmission of the target data packet has been completed.

[0010] Optionally, the domain controller is configured to generate control instructions based on the target message and send the control instructions to the terminal application to control the terminal application to execute the corresponding control instructions.

[0011] Secondly, embodiments of the present invention provide a road data transmission device, the device comprising: The planning module generates a planned route based on the vehicle's starting and destination positions in the map data. The acquisition module acquires road data for the first predetermined distance ahead of the vehicle in the planned path multiple times, based on the vehicle's current location. The encapsulation module encapsulates the acquired road data into a target data packet each time. The sending module sends the target data packet to the domain controller.

[0012] Thirdly, embodiments of the present invention provide an electronic device, including: At least one processor; and At least one memory communicatively connected to the processor, wherein: The memory stores program instructions that can be executed by the processor, which can invoke the program instructions to perform the method as described in any of the first aspects.

[0013] Fourthly, embodiments of the present invention provide a storage medium including a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to perform the method described in any of the first aspects.

[0014] Considering the redundancy that may occur when loading the entire planned path's road data at once, this embodiment of the invention uses a sliding window mechanism to transmit only the minimum dataset required by the vehicle in real time—that is, the data within a specific range ahead that the vehicle needs at a given moment. This greatly reduces network load and ensures extremely low latency and ultra-high real-time performance. In-vehicle communication is based on the mature, reliable, and widely adopted CAN bus protocol, inheriting its inherent high anti-interference and error detection capabilities. Furthermore, it eliminates the need to rely on high-bandwidth automotive Ethernet, significantly reducing the hardware cost for supporting warning and automatic driving functions. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 The diagram shown is a schematic representation of a road data transmission system provided in an embodiment of this application. Figure 2 The diagram shown is a flowchart of a road data transmission method provided in an embodiment of this application; Figure 3 The diagram shown is a schematic representation of a road data transmission device according to an embodiment of this application. Figure 4 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0018] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0019] like Figure 1 The diagram shown is a schematic representation of a road data transmission system provided in an embodiment of the present invention. (See also...) Figure 1 The road data transmission system includes: a map cloud server, a smart cockpit, and a domain controller.

[0020] Map cloud servers are used to provide map data.

[0021] The intelligent cockpit determines the starting and destination locations of the current journey after the user initiates navigation, and generates a planned route through a map cloud server. The intelligent cockpit also retrieves road data for each specific road along the planned route from the map cloud server, encapsulates the acquired road data into target data packets, and sends them to the domain controller.

[0022] In this embodiment of the invention, the intelligent cockpit uses a dynamic sliding window mechanism to encapsulate only a portion of the road data ahead of the vehicle during driving into a target data packet and send it to the domain controller. After driving a certain distance, the road data is retrieved again and pushed to the domain controller. Simultaneously, the transmitted road data is simplified, encapsulating only the critical road data necessary for assisted driving, such as slope and curvature, thereby significantly reducing the amount of data that needs to be sent and ensuring a real-time and reliable supply of road data.

[0023] The intelligent cockpit is connected to the domain controller via a CAN bus, thereby enabling the transmission of target data packets encapsulated in the intelligent cockpit to the domain controller through the CAN bus network.

[0024] The domain controller receives target data packets sent by the intelligent cockpit, parses and caches these packets to obtain road data for each road in the planned path. Combining this data with vehicle and environmental information collected by onboard and roadside sensors, it generates control commands. These commands are used to control the execution of corresponding terminal applications, such as lane departure warnings, economy driving modes, and turning speed warnings.

[0025] like Figure 2 The diagram shows a flowchart of a road data transmission method provided in an embodiment of the present invention. This method is applied to applications such as... Figure 1 The smart cockpit shown. See also Figure 2 The specific steps of this method include: S201, Based on the vehicle's starting and destination positions in the map data, a planned route is generated using the map data.

[0026] Specifically, based on the navigation instructions initiated by the user, the destination location is determined from the map cloud server, and a planned route is generated based on the map data in the map cloud server.

[0027] The intelligent cockpit also enables vehicle positioning and monitoring to obtain the vehicle's current location in real time. It determines the vehicle's starting position when the user initiates a navigation command, the destination planned by the user through the navigation command, and tracks the vehicle's journey from the starting position to the destination in real time.

[0028] S202: Based on the vehicle's current location, obtain road data for the first predetermined distance ahead of the vehicle in the planned path multiple times.

[0029] Specifically, when the vehicle's current location is the starting position, road data is acquired for the first time to push road data. The roads within a first predetermined distance ahead of the starting position in the map data are defined as the path window. Road data for each road within the path window is then acquired.

[0030] Generally, the first predetermined distance is usually set to 10km, that is, the road 10km ahead of the vehicle is used as the path window to obtain the road data of each road within the path to be traveled in the 10km ahead of the vehicle.

[0031] Optionally, during vehicle travel, the roads within the path window can be updated based on the vehicle's travel distance, thereby incrementally pushing road data.

[0032] Continuous location monitoring is performed on the vehicle to continuously acquire its position change information. Whenever the vehicle's position change within the planned path reaches a second predetermined distance, the road within the second predetermined distance ahead of the path window's endpoint is added to the path window, and the road data for each road within the path window is updated. This ensures that the vehicle can always acquire road data within a first predetermined distance ahead.

[0033] Typically, the second predetermined distance is set to 5km. In one embodiment, when the path window is 0-10km, and the vehicle travels to 5km, roads within 10-15km are added to the path window, updating the path window to 5-15km, thereby updating the road data for each road within the path window. The vehicle always acquires road data within 10km ahead.

[0034] Specifically, when the vehicle's position changes to the second predetermined distance in the planned path, and the remaining third distance of the planned path is less than the second predetermined distance, the road at the third distance ahead of the end point of the path window is directly added to the path window.

[0035] For example, if the path window is 0-10km, and the vehicle travels to 5km, only 3km of the planned path remains, then the roads within 10-13km are added to the path window, updating the path window to 5-13km, thereby updating and obtaining the road data for each road within the path window.

[0036] S203 encapsulates each acquired road data into a target data packet.

[0037] Specifically, after each acquisition of road data, such as when determining the planned route or when the vehicle's position changes to a second predetermined distance, it is necessary to acquire road data again and encapsulate the acquired road data into a target data packet.

[0038] When encapsulating target data packets, road data needs to be encapsulated into a start frame, at least one data frame, and an end frame.

[0039] The start frame is used to announce the start of a new target data packet push, and to indicate the amount of road data to be sent in this target data packet, as well as the starting point of the path window.

[0040] The start frame consists of 8 bytes, specifically bytes 0-7. Byte 0 indicates the message type, typically represented by 0xF0 as the start frame; byte 1 indicates the total number of road data segments to be sent within the path window of the target data message being pushed; bytes 2-3 indicate the starting point of the path window within the target data message being pushed, enabling the receiving domain controller to clearly identify which path segment corresponds to this data push, preventing data corruption when vehicle locations jump or are repeatedly pushed; bytes 4-7 are reserved for or store a checksum.

[0041] Data frames are used to transmit data for a single road, which describes the data of a road through attribute type information, the location where the attribute type begins to take effect, and the distance covered by the attribute type.

[0042] The data frame consists of 8 bytes, specifically byte 0 through byte 7. byte 0 indicates the message type, typically represented by 0xF1 for a data frame; byte 1 indicates the data sequence number (0-255); byte 2 indicates the attribute type, which describes the attributes of the road, including at least the speed limit, gradient, curvature, number of lanes, and road type; bytes 3-4 indicate the specific attribute values, ranging from -32768 to 32767; bytes 5-6 indicate the starting point of the corresponding road attribute type; and byte 7 indicates the distance covered by the corresponding road attribute type.

[0043] In a specific embodiment, the attribute type in byte2 can be represented by 0x01 to indicate the road speed limit, 0x02 to indicate the road gradient, 0x03 to indicate the road curvature, 0x04 to indicate the number of lanes, and 0x05 to indicate the road type, with reserves made to represent more attribute types.

[0044] Optionally, each pushed target data message can encapsulate multiple data frames to describe different attribute types of different roads in the path window.

[0045] The end frame indicates the end of the push of this target data packet. Optionally, the end frame may include a total checksum.

[0046] The end frame consists of 8 bytes, specifically byte 0 through byte 7. Byte 0 indicates the message type, typically represented by 0xF2 for the end frame. Bytes 1 through 7 represent the checksum, which could be the sum of attribute values ​​from all data frames.

[0047] S204, send the target data packet to the domain controller.

[0048] Specifically, the target data message, encapsulated as a start frame, data frame, and end frame, is sent to the domain controller via the CAN bus.

[0049] Although the CAN bus itself is reliable, in order to prevent data loss due to reasons such as lack of buffer space in the application layer of the domain controller, a request-acknowledgment mechanism can be used to allow the domain controller to send back an acknowledgment frame after receiving the target data message. The acknowledgment frame confirms that the target data message has been sent and has been received correctly.

[0050] The response frame is fed back to the smart cockpit by the domain controller via the CAN bus, indicating that the target data message has been correctly received.

[0051] The response frame consists of 8 bytes, specifically bytes 0-7. Byte 0 indicates the message type, typically represented by 0xF2. Byte 1 indicates the number of road data points successfully received; bytes 2-3 indicate the endpoint of the path window; bytes 4-7 are reserved.

[0052] When an acknowledgment frame is received, it is determined that the transmission of the target data packet has been completed; when no acknowledgment frame is received, data retransmission is triggered.

[0053] Upon receiving the target data packet, the domain controller generates control commands based on the road data contained within, combined with vehicle and environmental information collected by onboard and roadside sensors. These control commands are used to control the execution of corresponding terminal applications, such as implementing lane departure warnings, economy driving modes, and turning speed warnings.

[0054] Considering the redundancy that may occur when loading the entire planned path's road data at once, this embodiment of the invention uses a sliding window mechanism to transmit only the minimum dataset required by the vehicle in real time—that is, the data within a specific range ahead that the vehicle needs at a given moment. This greatly reduces network load and ensures extremely low latency and ultra-high real-time performance. In-vehicle communication is based on the mature, reliable, and widely adopted CAN bus protocol, inheriting its inherent high anti-interference and error detection capabilities. Furthermore, it eliminates the need to rely on high-bandwidth automotive Ethernet, significantly reducing the hardware cost for supporting warning and automatic driving functions.

[0055] The following is a specific embodiment provided by the present invention. In this embodiment, the user initiates a navigation route of 23km. Taking the push of road speed limit information as an example, the speed limit is 60km / h from 0-5km and 10-18km, 30km / h from 5-10km, and 80km / h from 18-23km.

[0056] When the vehicle is at the starting position, it acquires road data for the first predetermined distance ahead, that is, it acquires speed limit information 60 and 30 at 0-10km, encapsulates it into a target data message, and pushes the data for the first time to send it to the domain controller.

[0057] The vehicle continues to move forward. When the vehicle's position changes to the second predetermined distance, that is, when the vehicle has traveled 5km and reached the 5km mark, it updates and obtains the speed limit information 60 at the 10-15km mark, encapsulates it into a target data packet, and pushes incremental data to the domain controller.

[0058] The vehicle continues to move forward. When the vehicle's position changes again to reach the second predetermined distance, that is, when the vehicle has traveled another 5km and reached 10km, it updates and obtains the speed limit information 60 and 80 at 15-20km, encapsulates it into a target data message, and pushes incremental data to send it to the domain controller.

[0059] The vehicle continues to move forward. When the vehicle's position changes again to reach the second predetermined distance, that is, when the vehicle has traveled another 5km and reached 15km, since the remaining third distance of 3km is less than the second predetermined distance, the speed limit information 80 at 20-23km is updated, encapsulated into a target data packet, and incremental data is pushed to the domain controller.

[0060] In addition to acquiring the road speed limit each time, other road data of different attribute types, such as road slope, are also acquired. The transmission method is the same as that for the road speed limit, and will not be described in detail in this embodiment.

[0061] Corresponding to the above-described road data transmission method, this application also provides a road data transmission device. See [link to relevant documentation]. Figure 3 This is a schematic diagram of a road data transmission device provided in an embodiment of this application. The road data transmission device may include: a planning module 301, an acquisition module 302, an encapsulation module 303, and a sending module 304.

[0062] The planning module 301 generates a planned path based on the vehicle's starting and destination positions in the map data.

[0063] The acquisition module 302 acquires road data of the first predetermined distance ahead of the vehicle in the planned path multiple times, based on the current position of the vehicle.

[0064] The encapsulation module 303 encapsulates the acquired road data into a target data packet each time.

[0065] The sending module 304 sends the target data packet to the domain controller.

[0066] Figure 4 This is a schematic diagram illustrating the structure of one embodiment of the electronic device described in this specification. Specifically, the electronic device can be implemented as a vehicle performing the road data transmission method provided in this embodiment. Figure 4 As shown, the electronic device may include at least one processor; and at least one memory communicatively connected to the processing unit, wherein the memory stores program instructions executable by the processing unit, and the processor can execute the road data transmission method provided in this embodiment by calling the program instructions.

[0067] The aforementioned electronic device can be a device capable of intelligent dialogue with the user, such as a cloud server. This specification does not limit the specific form of the electronic device in the embodiments. It is understood that the electronic device here refers to the machine mentioned in the method embodiments.

[0068] Figure 4 A block diagram of an exemplary electronic device suitable for implementing embodiments of this specification is shown. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments described in this specification.

[0069] like Figure 4 As shown, the electronic device is represented in the form of a general-purpose computing device. The components of the electronic device may include, but are not limited to: one or more processors 410, communication interface 420, memory 430, and communication bus 440 connecting different system components (including memory 430, communication interface 420 and processor 410).

[0070] Communication bus 440 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MAC) buses, Enhanced ISA buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses.

[0071] Electronic devices typically include a variety of computer-readable media. These media can be any available media that can be accessed by the electronic device, including volatile and non-volatile media, and removable and non-removable media.

[0072] Memory 430 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The electronic device may further include other removable / non-removable, volatile / non-volatile computer system storage media. Memory 430 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments described herein.

[0073] A program / utility having a set (at least one) of program modules may be stored in memory 430. Such program modules include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The program modules typically perform the functions and / or methods described in the embodiments of this specification.

[0074] The processor 410 executes various functional applications and data processing by running programs stored in the memory 430, such as implementing the road data transmission method provided in the embodiments shown in this specification.

[0075] This specification provides a non-transitory computer-readable storage medium that stores computer instructions that cause the computer to execute the road data transmission method provided in the embodiments shown in this specification.

[0076] The aforementioned non-transitory computer-readable storage medium may be any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in connection with an instruction execution system, apparatus, or device.

[0077] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0078] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0079] Computer program code for performing the operations described herein can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0080] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0081] 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 specification, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0082] 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 executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this specification 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 will be understood by those skilled in the art to which the embodiments of this specification pertain.

[0083] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0084] It should be noted that the terminals involved in the embodiments of this specification may include, but are not limited to, personal computers (PCs), personal digital assistants (PDAs), wireless handheld devices, tablet computers, mobile phones, MP3 players, MP4 players, etc.

[0085] In the embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0086] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0087] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this specification.

[0088] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A method for transmitting road data, characterized in that, The method includes: Based on the vehicle's starting and destination locations in the map data, a planned route is generated using the map data. Based on the vehicle's current location, road data for the first predetermined distance ahead of the vehicle in the planned path is obtained multiple times; Each time the road data is acquired, it is encapsulated into a target data packet; The target data packet is sent to the domain controller.

2. The method according to claim 1, characterized in that, The step of repeatedly acquiring road data for a first predetermined distance ahead of the vehicle in the planned path based on the vehicle's current position includes: When the vehicle's current position is the starting position, the road within a first predetermined distance in front of the starting position in the map data is determined as the path window; Obtain the road data for each road within the path window.

3. The method according to claim 2, characterized in that, After obtaining the road data of each road within the path window, the method further includes: Continuously acquire vehicle location change information; Whenever the vehicle's position changes to a second predetermined distance in the planned path, the road within the second predetermined distance in front of the end point of the path window is added to the path window. Update the road data of each road within the path window; Specifically, when the vehicle's position changes by a second predetermined distance in the planned path, and the remaining third distance of the planned path is less than the second predetermined distance, the road at the third distance ahead of the end point of the path window is added to the path window.

4. The method according to claim 1, characterized in that, The step of encapsulating the acquired road data into a target data packet each time includes: The road data is encapsulated into a start frame, at least one data frame, and an end frame.

5. The method according to claim 4, characterized in that, include: The start frame is used to announce the start of data push and to represent the number of road data to be sent in this target data packet, as well as the starting point of the path window; The data frame is used to characterize the attribute type information of road data, the location where the attribute type begins to take effect, and the distance covered by the attribute type. The attribute type information includes at least road speed limit, road gradient, road curvature, number of lanes, and road type. The end frame is used to indicate the end of the push of this target data packet.

6. The method according to claim 1, characterized in that, After sending the target data packet to the domain controller, the method further includes: Receive a response frame sent by the domain controller, the response frame being used to indicate that the domain controller has received the target data packet; When the response frame is received, it is determined that the transmission of the target data packet has been completed.

7. The method according to claim 1, characterized in that, The domain controller is used to generate control instructions based on the target message and send the control instructions to the terminal application to control the terminal application to execute the corresponding control instructions.

8. A road data transmission device, characterized in that, The device includes: The planning module generates a planned route based on the vehicle's starting and destination positions in the map data. The acquisition module acquires road data for the first predetermined distance ahead of the vehicle in the planned path multiple times, based on the vehicle's current location. The encapsulation module encapsulates the acquired road data into a target data packet each time. The sending module sends the target data packet to the domain controller.

9. An electronic device, characterized in that, include: At least one processor; as well as At least one memory communicatively connected to the processor, wherein: The memory stores program instructions that can be executed by the processor, and the processor can invoke the program instructions to perform the method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 7.

Images