ADAS map updating and path planning system and method

Abstract

The invention discloses an ADAS map updating and path planning system and method. The ADAS map updating and path planning system comprises a data acquisition module which acquires and preprocesses vehicle end and environment data and then uploads the vehicle end and environment data to a cloud end; the cloud processing module compares the data and judges that a corresponding position map needs to be updated when the data deviates; the map updating module generates an incremental updating package after receiving the request, and generates a latest map through hot updating; the path planning module calculates a path based on an algorithm and returns the path to the vehicle end; after updating the local cache, the electronic horizon line module encapsulates road data of a preset distance in front of the vehicle and sends the data to the planning and control module, and the planning and control module generates a control instruction to enable the vehicle end to run according to a planned path. The problems that a traditional static map system is long in updating time consumption, single in path calculation dimension and incapable of supporting multi-vehicle cooperation are solved, and map updating time consumption lt is achieved; the concurrent requests of 150 vehicles are delayed at 1t in 3 seconds; and the method has the effect of road-level precision.

Description

Technical Field

[0001] This invention belongs to the field of automotive technology, specifically relating to an ADAS map update and route planning system and method. Background Technology

[0002] With the development of autonomous driving technology, maps have become an indispensable core component of Level 2 and above Advanced Driver Assistance Systems (ADAS) and Autonomous Driving Systems (ADS). Unlike traditional navigation maps, which primarily provide guidance to human drivers, maps provide vehicle control systems with precise geometric information and rich semantic information, serving as a key basis for achieving accurate positioning, environmental perception, path planning, and decision-making control.

[0003] However, the effectiveness of a map is highly dependent on its freshness and accuracy. Road networks are not static; dynamic events such as temporary road construction, lane closures, traffic sign changes, and the opening of new intersections occur frequently, requiring maps to have the ability to be updated quickly. Currently, the industry mainly faces the following technical bottlenecks in map generation and updating: Firstly, most mainstream map update processes currently follow a periodic update model dominated by map providers. This model typically relies on a fleet of professional data collection vehicles to collect road data, followed by a lengthy backend processing, mapping, quality inspection, and distribution process. Finally, the update package must be delivered to the vehicle via OTA (Over-The-Air) updates, often requiring the vehicle to be turned off or parked to prevent the update process from consuming system resources and affecting real-time driving functions. However, this traditional update process takes an extremely long time on average from data collection to vehicle application completion, impacting the user experience.

[0004] Secondly, the electronic horizon function is responsible for predicting the vehicle's forward path. Existing system path prediction algorithms often rely too heavily on a single factor, such as primarily considering historical paths or the shortest distance. This single-dimensional decision-making model performs poorly in complex road scenarios (such as dense ramps, large roundabouts, and grade-separated traffic junctions), making it difficult to accurately predict the driver's true intentions and the most reasonable driving path, which can easily lead to system misjudgments and trigger unnecessary warnings.

[0005] Third, traditional vehicle-side computing architectures store map data locally, and route calculation and electronic horizon generation are primarily completed within the vehicle. This closed architecture struggles to support large-scale collaborative computing and real-time updates based on crowdsourced data, leading to a sharp increase in cloud service response latency and even service crashes. Summary of the Invention

[0006] The purpose of this invention is to propose an ADAS map update and route planning system and method to solve the problems in the prior art.

[0007] Therefore, the present invention provides an ADAS map update and route planning system, comprising: The data acquisition module is used to collect multiple vehicle-side data and environmental data, and after preprocessing the vehicle-side data and environmental data, upload them to the cloud. The cloud processing module receives the data uploaded by the data acquisition module, processes it according to preset conditions, compares it with the current map, and determines that the map at the current location needs to be updated when there is a discrepancy in the data. The map update module receives an update request, generates incremental map updates, performs hot map updates, and generates the latest map. A route planning module, which calculates a route based on an algorithm and returns the route data to the vehicle. The electronic horizon module, after issuing a request command, receives the path data returned by the path planning module, updates the local cache, encapsulates the road data of the preset distance ahead of the vehicle in the path data, and sends it to the planning and control module. After receiving the road data, the planning and control module generates control commands to enable the vehicle to travel along the planned path.

[0008] Preferably, the data acquisition module includes a GNSS module, a GPS / IMU positioning module, a vehicle CAN bus, and a camera.

[0009] Preferably, it also includes a cloud service instance module, which, after receiving a request instruction from the electronic horizon module, reads a road list from the latest map data.

[0010] Preferably, it also includes a map matching module, which receives the road list returned by the cloud service implementation module, and combines the vehicle data fed back by the data acquisition module with the electronic horizon module to generate an MPP list, and outputs the corrected latitude and longitude, Link ID, lateral offset and heading angle deviation.

[0011] On the other hand, an ADAS map updating and route planning method is also provided, characterized by including: Collect multiple vehicle-side data and environmental data, and then upload the vehicle-side data and environmental data to the cloud after preprocessing them; The system receives vehicle-side data and environmental data, processes them according to preset conditions, and compares the data with the current map. If a discrepancy is found, the map at the current location is determined to need to be updated. When an update is required, an incremental map update package is generated, the old version map service is stopped and resources are released, and the new version map service is enabled. The new version map is generated by combining the old version map with the incremental map update package. Receive route planning requests initiated by the vehicle, and calculate the driving route and corresponding road attributes based on the new version of the map and at least in combination with the vehicle's steering angle, road grade difference, and road exit.

[0012] Preferably, after processing according to preset conditions, the data is compared with the current map. When a discrepancy is found, it is determined that the map at the current location needs to be updated, including: Within the same geographical location and a preset time period, determine whether the number of vehicles sending abnormal data is greater than a preset vehicle threshold. If it is greater than or equal to the threshold, determine that the map at the current location needs to be updated. If the value is less than the value, then the map at the current location does not need to be updated.

[0013] Preferably, upon receiving a route planning request initiated by the vehicle, the driving route and corresponding road attributes are calculated using the following formula, based on the new version of the map and at least in combination with the vehicle's steering angle, road grade difference, and road exits: ; Where Wangle is the steering angle weight, Wfrc is the road grade difference weight, Cfrc is the first fixed coefficient, Wexit is the road exit weight, and k is the second coefficient that varies according to the road scene type.

[0014] Preferably, the formula for calculating the steering angle weight is: ; Where θ is the vehicle steering angle and Cangle is the third fixed coefficient.

[0015] Preferably, the method further includes receiving the driving path and corresponding road attributes on the vehicle side, updating the vehicle side's local electronic horizon cache, and updating the road information ahead in the driving path.

[0016] Preferably, it also includes generating a dynamic path cache to continuously accumulate the length of the path that the vehicle has already traversed; When the cumulative length exceeds a preset trailing length threshold, the oldest road link is trimmed so that the length of the road behind the vehicle in the cache does not exceed the preset trailing length threshold.

[0017] Beneficial effects: This invention solves the technical problems of traditional static map systems, such as excessively long update times requiring manual intervention, single-dimensional path calculation, and closed systems that cannot support multi-vehicle collaboration, by enabling uninterrupted hot updates of map services, a multi-factor path decision algorithm that integrates steering angle, road grade difference, and exit link priority, and real-time push of road-level data that supports high-concurrency vehicle-cloud collaboration. It achieves map update time of less than 3 seconds, latency of less than 800ms under concurrent requests from 150 vehicles, and provides road-level accuracy. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram of the ADAS map update and route planning system provided by the present invention.

[0020] Figure 2 This is a flowchart illustrating the ADAS map updating and path planning method provided by the present invention.

[0021] Figure 3 This is a flowchart for determining whether a map needs to be updated in the ADAS map updating and path planning method provided by the present invention.

[0022] Figure 4 This is a flowchart illustrating the path planning calculation process in the ADAS map update and path planning method provided by the present invention.

[0023] In the diagram: 1. Data acquisition module; 2. Data request receiving application module; 3. Map matching module; 4. Electronic horizon module; 5. Planning and control module; 6. Data forwarding module; 7. Map version controller; 8. Map download module; 9. Dispatch center; 10. Service instance module; 11. Route planning module. Detailed Implementation

[0024] The invention will be more readily understood by referring to the following detailed description of preferred embodiments and included examples. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. In case of conflict, the definitions in this specification shall prevail.

[0025] like Figure 1 As shown, an ADAS map update and route planning system includes: The data acquisition module 1 is used to collect multiple vehicle-side data and environmental data, and after preprocessing the vehicle-side data and environmental data, it uploads them to the cloud. In one embodiment, the data acquisition module 1 includes a fusion positioning unit composed of a GNSS module and an IMU module, which can collect the high-precision position of the vehicle, with a positioning accuracy of ±5m. The data acquisition module 1 also includes a vehicle CAN bus to obtain vehicle status data such as steering angle and speed. That is, the vehicle-side data includes at least vehicle position data and vehicle status data. In one embodiment, the data acquisition module 1 also includes a camera, which can collect environmental image data, specifically information such as roadside speed limit signs, cones, and road closure status. The vehicle-side data and environmental data collected are all crowdsourced data from the vehicle side. By simultaneously collecting and uploading multiple crowdsourced data from the vehicle side to the cloud, the cloud can promptly update the map and plan new routes when road conditions change, avoiding problems such as untimely map updates affecting driving experience and safety.

[0026] The cloud processing module receives data uploaded by the data acquisition module 1, processes it according to preset conditions, and compares it with the current map. If a discrepancy is found, the map at the current location is determined to need updating. In one embodiment, the remote processing module can be deployed on a server, such as Tencent Cloud. After receiving data from multiple vehicles at high concurrency through components such as Kafka, the cloud processing module aggregates the data according to geographical location and time to form a dense point cloud of road units. Then, it compares the actual situation reflected by the crowdsourced data, such as vehicle trajectories and identified signs, with the existing map. When a sufficient number of vehicles report abnormal data with the same characteristics at a certain location within a specific time, the map at that location is determined to need updating. For example, abnormal data with the same characteristics includes detecting the same speed limit sign.

[0027] The map update module, upon receiving an update request, generates incremental map updates and performs hot map updates to produce the latest map. In one embodiment, this is achieved by generating an incremental map update package in NDS format. The map update module includes a map download module 8, which downloads the incremental map update package to a temporary cloud cache and verifies the integrity of the data package using a verification module, specifically through MD5 hash value verification. A seamless switch between the old and new maps is executed through a service management module. Specifically, the old version map reading service is securely stopped, releasing its resources, while the activated map path is redirected to the new version data directory, and then the new version map reading service is started. The entire process takes less than 3 seconds, achieving a seamless switch and effectively improving the user experience. This solves the problem of existing technologies requiring significant time for updates, leading to untimely updates and affecting normal driving.

[0028] The path planning module 11 calculates the path based on an algorithm and returns the path data to the vehicle. In one embodiment, it calculates the MMP path and first-level sub-paths by combining multi-factor decision-making. Specifically, it can consider the steering angle to determine how many degrees the steering wheel has been turned, thereby determining the driver's intention to go straight, turn left, or turn right, with straight-going having a higher weight and left and right turns having lower weights. It can also consider road grade differences, classifying roads as highways, expressways, arterial roads, and side roads, with highways and expressways having higher weights and side roads having lower weights. Furthermore, it can consider road exits, such as in complex roundabouts and interchanges, prioritizing exits less likely to lead to the wrong exit. The optimal driving path is obtained through weighted calculation.

[0029] The electronic horizon module 4, after issuing a request command, receives path data returned by the path planning module 11. After updating its local cache, it encapsulates the road data representing the preset distance ahead of the vehicle from the path data and sends it to the planning and control module 5. In one embodiment, when the vehicle reaches a certain location, the electronic horizon module 4, as needed, sends three requests to the cloud through the data request receiving application module: first, a road topology request, to obtain information about surrounding roads based on the current location; second, a metadata request, to obtain the country code, map provider, and map version number of the road; and third, a request for optimal driving route.

[0030] The cloud service instance module 10 receives the above request, the map data reading service module reads data from the latest map, and calculates the MMP path and first-level sub-paths in conjunction with the path planning module 11, and feeds back the results, such as road list, attributes and planned path, to the vehicle.

[0031] After receiving the road list from the cloud, the map matching module 3 in the planning and control module 5 fuses and matches it with local sensor data and the MMP list predicted by the electronic horizon, and outputs a centimeter-level positioning structure, specifically including the precise Link ID, corrected latitude and longitude, lateral offset, and heading angle deviation. Simultaneously, the electronic horizon module 4 receives path and attribute data returned from the remote end, updates the local cache, maintains the continuity of the MMP path, and dynamically trims the path behind the vehicle to maintain a 100-meter trail. At the same time, road data within a maximum range of 1000 meters in front of the vehicle is encapsulated according to the ADASISv2 protocol and sent to the downstream planning and control module 5. Upon receiving the road data, the vehicle-side planning and control module 5 generates control commands to enable the vehicle to drive according to the planned path. In one embodiment, this enables ADAS functions such as lane keeping, adaptive cruise control, and automatic lane changing.

[0032] Meanwhile, as the vehicle continues to generate new data during its journey, the process returns to the initial stage, forming a continuously optimized closed loop.

[0033] Through the above technical solutions, by adopting a three-level caching architecture and a seamless "download-verify-switch" service switching mechanism, the problems of traditional static map updates requiring vehicle shutdown and averaging 138 seconds of manual intervention are solved, achieving a map update time of less than 3 seconds. Simultaneously, by comprehensively calculating the optimal path based on three factors—steering angle, road grade difference, and exit link priority—the single-dimensionality problem of traditional path planning, which only considers path distance, is overcome, resulting in path decision-making that better reflects driver intent and actual road conditions. Finally, through cloud architecture optimization based on MQTT and Kafka message middleware, the system's closed nature—where a single-vehicle computing architecture cannot support multi-vehicle collaboration (up to 50 vehicles)—is resolved, achieving the effect of supporting real-time road-level data push from 150 vehicles simultaneously with a latency of less than 800ms.

[0034] In one embodiment, the vehicle-side can use an Invensense GPS / IMU positioning module, with a positioning accuracy error of no more than 5 meters when the GPS signal is good. The cloud-side can use Tencent Cloud, specifically an 8-core, 32GB configuration, with a Kafka message throughput of at least 120,000 messages per second.

[0035] In one embodiment, the GNSS module is responsible for periodically collecting GPS information to provide accurate geographic location data for the vehicle system, and the GNSS module can also perform automatic calibration.

[0036] In one embodiment, the map matching module 3, after receiving the raw pose data output by GNSS / IMU fusion, such as latitude, longitude, heading angle, and velocity in the WGS84 coordinate system, performs coordinate transformation through a deflection plugin, for example, converting the WGS84 coordinate system to the coordinate system corresponding to GCJ02 / BD09.

[0037] Then, based on the deflected latitude and longitude, a road topology request is sent to the cloud via the mapClient module. The cloud-returned list of links is received. This list is then merged with the MPP link list from the electronic horizon module 4 and the cloud-based road list to output a high-precision link ID conforming to the NDS standard, with a corrected latitude and longitude error of less than 20cm. Lateral offset and heading angle deviation can also be output.

[0038] In one embodiment, the electronic horizon module 4 receives and processes event responses, including location updates, requests to obtain surrounding road topology, system service control, module software version collection, obtaining metadata feedback results, and path calculation feedback results. Obtaining the surrounding road topology request requires calling the data request receiving application module interface. Based on the location linkid, a request to obtain metaData is sent, and the application module interface for receiving data requests is invoked. Send a path calculation request based on the location linkid and call the data request receiving application module interface; Receive the metaData feedback results, calculate the administrative region code, and send the METADATA message to protobuf; Receive path calculation feedback results, update the cached path, and maintain MPP path continuity; As required, road data (including first-level sub-road path data) within a maximum 1km range of the MPP path ahead of the vehicle's location is sent to protobuf according to the ADASIS v2 protocol. The transmission range extends forward as the vehicle's location moves. It supports filtering ADAS attribute points, supports PSV_BANDWIDTH mode, sends slope and curvature attribute data, and supports sending road speed limit data; MPP path management, effective path length control (deleting roads that exceed the maximum trailing distance); Send MPP link list event.

[0039] In one embodiment, it also includes a vehicle-side data request application module, which sends the Topic corresponding to the request to obtain the surrounding road topology to the MQTT. Send the Topic corresponding to the request to retrieve metaData to MQTT; Send the Topic corresponding to the path calculation request to MQTT; Subscribe to receive the Topic corresponding to the surrounding road topology feedback and send the data to the map matching module 3; Subscribe to receive the Topic corresponding to the metaData feedback and send the data to the eHorizon module 4; Subscribe to the Topic corresponding to the path calculation feedback and send the data to the Electronic Horizon module 4; In one embodiment, it also includes a data forwarding module 6, which is responsible for receiving data streams from the vehicle and implementing high-concurrency message routing through a distributed cluster. It adopts an asynchronous architecture design that separates the message routing plane from the monitoring and management plane.

[0040] In one embodiment, the service instance module 10 includes map data reading and management, which can read map data resources in real time based on requests, and can also provide path calculation, i.e. the multi-factor path calculation mentioned above, which will not be repeated here.

[0041] In one embodiment, a map management service scheduling hub 9 is also included, which coordinates the map data processing flow, manages the request and response lifecycle, and monitors the load of the service instance module 10 and dynamically allocates tasks.

[0042] In one embodiment, the system also includes a map version controller 7, which receives NDS map data packets published by map providers through a Kafka message queue, caches the original data packets to the / cache temporary area, provides the issuance and management of resource download addresses, and publishes download commands MQTT Topic.

[0043] In one embodiment, the map download module 8 downloads the map data package to a temporary path, decompresses the map data package and persistently stores it to a specified path, and then deletes the map data package.

[0044] like Figure 2-3 As shown, on the other hand, this application also provides an ADAS map updating and route planning method, including: Collect multiple vehicle-side data and environmental data, and then upload the vehicle-side data and environmental data to the cloud after preprocessing them; The system receives vehicle-side data and environmental data, processes them according to preset conditions, and compares the data with the current map. If a discrepancy is found, the map at the current location needs to be updated. In one embodiment, the IMU and GNSS module constitute a fusion positioning unit to acquire vehicle positioning data. A camera can also be installed to collect road environment image data. During data acquisition, the positioning unit collects vehicle latitude and longitude (WGS84 coordinate system), heading angle, acceleration, and other positioning data at a frequency of 10Hz. The CAN bus collects vehicle-side data such as steering angle (range -180°~180°), vehicle speed (unit km / h), and braking status at a frequency of 5Hz. The camera collects environmental image data such as lane lines, traffic signs, and temporary construction areas within a 50m range ahead at a frequency of 2Hz.

[0045] For positioning data, a Kalman filter algorithm is used to remove jump data caused by GNSS signal obstruction (such as in tunnels or high-rise areas), correcting the positioning accuracy to ±0.3m. For CAN bus data, a data cleaning module filters redundant and erroneous frames generated during transmission, retaining valid data fields. For environmental image data, a lightweight YOLOv8 model is used for target detection, extracting semantic information such as lane line type (solid / dashed lines), traffic sign content (speed limit 60km / h, no overtaking), and temporary obstacles (construction cones), and converting the image data into structured data in NDS (NavigationDataStandard) format. After preprocessing, the fused vehicle-side data and environmental data are uploaded to Tencent Cloud server via the MQTT protocol (message transmission latency <100ms).

[0046] When an update is required, an incremental map update package is generated, the old version map service is stopped and resources are released, and the new version map service is enabled. The new version map is generated by combining the old version map with the incremental map update package. In one embodiment, upon receiving an update request, an incremental map update package is first generated based on the current map and the abnormal data uploaded by the vehicle. This incremental package contains only key data (approximately 5MB) of the changed area, specifically including: the correction of the number of lanes in the eastbound direction at the XX Road intersection (from 2 lanes to 1 lane), the coordinate range of the construction area (30°15′20″~30°15′24″ N, 120°10′33″~120°10′37″ E), and construction signs and pedestrian boundary adjustment data, thus avoiding resource waste caused by a full map update.

[0047] Then, the map hot update process is executed: The first step is to download the incremental update package to the cloud temporary storage area (path: / cache / adas_map / update_package / ) and verify the data integrity by using the MD5 hash value (verification value: 7a3f2d4e8b9c10e5f6a7b8c9d0e1f2a3); The second step is to stop the process of the old version map service (V2.3.1) (process ID: 12345), and release the memory (approximately 2GB) and file handles (128 in total) occupied by the service. The entire release process takes less than 1 second. The third step is to merge the incremental update package with the old version map to generate the new version map, and initialize the new version map service, loading the index file and attribute database of this version map. The service initialization time is less than 2 seconds. Finally, the entire process from stopping the old service to starting the new service takes 2.8 seconds, achieving uninterrupted switching of map services. During this period, all route planning requests from each vehicle are responded to by the new version map service, with no request loss or delay overdue (delay < 800ms).

[0048] Receive route planning requests initiated by the vehicle, and calculate the driving route and corresponding road attributes based on the new version of the map and at least in combination with the vehicle's steering angle, road grade difference, and road exit.

[0049] like Figure 4 As shown, in one embodiment, the driver initiates a route planning request through the vehicle terminal. After receiving the request, the cloud route planning module 11 calculates the optimal driving route based on the new version of the map and combined with the vehicle's current status data, such as the steering angle θ=0°, the current road being an urban arterial road, FRC=2, and road attributes, using a weighted formula.

[0050] Specifically, it is calculated using the following formula: ; Where Wangle is the steering angle weight, Wfrc is the road grade difference weight, Cfrc is the first fixed coefficient, Wexit is the road exit weight, and k is the second coefficient that varies according to the road scene type.

[0051] The formula for calculating the steering angle weight is as follows: ; Where θ is the vehicle steering angle and Cangle is the third fixed coefficient.

[0052] In this embodiment, ; The current road is an urban arterial road with a priority level of Pclass=3. The target path is to select an urban expressway with a priority level of FRC=1. According to the formula ; =0.799, the first fixed parameter Cfrc=0.2. Therefore, Wfrc*Cfrc=0.16.

[0053] The target path needs to pass through an exit on a regular road, so Wexit = 0.8, the second coefficient K = 0.4, and therefore Wexit*K = 0.32.

[0054] Substitute into the weighted formula =0.88. At the same time, the route planning module 11 also calculated the Wpath values ​​of the other two alternative routes, which were 0.75 and 0.68 respectively. Finally, the route with a value of 0.88 was selected as the optimal driving route, and the road attribute data of the route was extracted, including the speed limit, gradient, curvature and number of lanes of each road segment, and returned to the taxi's vehicle-side system through the MQTT protocol.

[0055] After receiving the optimal driving path and road attributes, the vehicle updates the local electronic horizon cache and encapsulates the road data within a 1KM range ahead into the ADASISv2 protocol format, which is then sent to the planning and control module 5. This module generates control commands such as acceleration, steering, and braking to enable the vehicle to drive along the planned path. The entire path planning and command generation process takes 5.86ms, which meets the real-time requirements.

[0056] In one embodiment, after processing according to preset conditions, the data is compared with the current map. When a discrepancy is found, it is determined that the map at the current location needs to be updated, including: like Figure 3As shown, within the same geographical location and a preset time period, the system determines whether the number of vehicles sending abnormal data exceeds a preset vehicle threshold. If it does, the map for the current location needs to be updated. The same geographical location is represented by a 10m x 10m grid cell, and the preset time period is 1 hour. Abnormal data is defined as the deviation between the semantic information collected by the vehicle and the current map data exceeding a preset threshold. For example, the preset threshold might be a lane line position deviation greater than 50cm, inconsistent traffic sign content, or newly added temporary construction areas not marked on the map.

[0057] If the value is less than the given value, then the map at the current location does not need to be updated.

[0058] In this embodiment, the preset vehicle threshold is set to 10 vehicles. That is, when ≥10 vehicles upload the same type of abnormal data within a certain grid cell within 1 hour, it is determined that the map at that location needs to be updated; if the number of vehicles is <10, it is determined to be a single vehicle-mounted device error or a temporary incident, and no update is required.

[0059] For example, at a certain road intersection, within one hour, 12 vehicles uploaded abnormal data stating that "the original map marked two lanes in the east-to-west direction, but in reality, due to construction, it has been reduced to one lane, and the newly added construction area occupies the sidewalk." The cloud processing module counted the number of vehicles with abnormal data in this area as 12, which meets the preset threshold of "≥10 vehicles". Therefore, it was determined that the map at this location needs to be updated, and an update request was sent to the map update module.

[0060] In one embodiment, the vehicle also receives the driving path and corresponding road attributes, updates the vehicle's local electronic horizon cache, and updates the road information ahead in the driving path.

[0061] In one embodiment, the method further includes generating a dynamic path cache to continuously accumulate the length of the path that the vehicle has traversed; When the cumulative length exceeds the preset trailing length threshold, the oldest road link is trimmed so that the length of the road behind the vehicle in the cache does not exceed the preset trailing length threshold.

[0062] The specific implementation steps include: Initialize the cumulative tracking length to 0; Iterate through each link ID in the current tracing link set: If it is the link the vehicle is currently on, determine the link direction (forward / reverse). If it is forward, add the vehicle's offset in the link; if it is reverse, add the total link length minus the offset. If it is another link, directly add the total link length. Returns the cumulative tracking length value.

[0063] It also includes a method for dynamically updating the cached path trailing list, specifically including: Get the current cumulative tracking length and the configured maximum tracking threshold. When the number of tracking links is greater than or equal to 2, the loop executes continuously, retrieves the oldest link ID and its length, calculates the remaining length after deleting the link, determines whether the remaining length still meets the threshold requirement, if it does, removes the link from the set, updates the remaining cumulative length, removes all associated links and sub-paths before the link, and accumulates the length of the traversed paths, if the threshold requirement is not met, the loop terminates.

[0064] It can achieve dynamic memory management, automatically maintain the optimal amount of path tracking data, and ensure that the system always retains the necessary historical path information through threshold control. It can also support bidirectional path calculation to adapt to complex road network scenarios, and finally achieve centimeter-level accuracy processing to meet the high-precision positioning requirements of autonomous driving.

[0065] Finally, it should be noted that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An ADAS map update and route planning system, characterized in that, include: The data acquisition module is used to collect multiple vehicle-side data and environmental data, and after preprocessing the vehicle-side data and environmental data, upload them to the cloud. The cloud processing module receives the data uploaded by the data acquisition module, processes it according to preset conditions, compares it with the current map, and determines that the map at the current location needs to be updated when there is a discrepancy in the data. The map update module receives an update request, generates incremental map updates, performs hot map updates, and generates the latest map. A route planning module, which calculates a route based on an algorithm and returns the route data to the vehicle. The electronic horizon module, after issuing a request command, receives the path data returned by the path planning module, updates the local cache, encapsulates the road data of the preset distance ahead of the vehicle in the path data, and sends it to the planning and control module. After receiving the road data, the planning and control module generates control commands to enable the vehicle to travel along the planned path.

2. The ADAS map update and route planning system according to claim 1, characterized in that, The data acquisition module includes a GNSS module, a GPS / IMU positioning module, a vehicle CAN bus, and a camera.

3. The ADAS map update and route planning system according to claim 1, characterized in that, It also includes a cloud service instance module, which, after receiving a request instruction from the electronic horizon module, reads a road list from the latest map data.

4. The ADAS map update and route planning system according to claim 1, characterized in that, It also includes a map matching module, which receives the road list returned by the cloud service implementation module, and combines the vehicle data fed back by the data acquisition module with the electronic horizon module to generate an MPP list, and outputs the corrected latitude and longitude, Link ID, lateral offset and heading angle deviation.

5. A method for ADAS map updating and path planning, characterized in that, include: Collect multiple vehicle-side data and environmental data, and then upload the vehicle-side data and environmental data to the cloud after preprocessing them; The system receives vehicle-side data and environmental data, processes them according to preset conditions, and compares the data with the current map. If a discrepancy is found, the map at the current location is determined to need to be updated. When an update is required, an incremental map update package is generated, the old version map service is stopped and resources are released, and the new version map service is enabled. The new version map is generated by combining the old version map with the incremental map update package. Receive route planning requests initiated by the vehicle, and calculate the driving route and corresponding road attributes based on the new version of the map and at least in combination with the vehicle's steering angle, road grade difference, and road exit.

6. The method according to claim 5, characterized in that, After processing according to preset conditions, the data is compared with the current map. If a discrepancy is found, it is determined that the map at the current location needs to be updated, including: Within the same geographical location and a preset time period, determine whether the number of vehicles sending abnormal data is greater than a preset vehicle threshold. If it is greater than or equal to the threshold, determine that the map at the current location needs to be updated. If the value is less than the value, then the map at the current location does not need to be updated.

7. The method according to claim 5, characterized in that, Upon receiving a route planning request from the vehicle, the system calculates the driving route and corresponding road attributes based on the new map version and at least the vehicle's steering angle, road grade difference, and road exits using the following formula: ; Where Wangle is the steering angle weight, Wfrc is the road grade difference weight, Cfrc is the first fixed coefficient, Wexit is the road exit weight, and k is the second coefficient that varies according to the road scene type.

8. The method according to claim 7, characterized in that, The formula for calculating the steering angle weight is: ; Where θ is the vehicle steering angle and Cangle is the third fixed coefficient.

9. The method according to claim 5, characterized in that, It also includes the vehicle receiving the driving path and corresponding road attributes, updating the vehicle's local electronic horizon cache, and updating the road information ahead in the driving path.

10. The method according to claim 5, characterized in that, It also includes generating a dynamic path cache to continuously accumulate the length of the path that a vehicle has already traversed; When the cumulative length exceeds a preset trailing length threshold, the oldest road link is trimmed so that the length of the road behind the vehicle in the cache does not exceed the preset trailing length threshold.

Images