A natural language description method of a drivable road network based on road points

Abstract

The application discloses a kind of natural language description method of road network based on road point, belong to the traffic simulation technical field based on deep learning.Solve the problem that traditional road network description method in prior art is difficult to obtain the position of vehicle and its surrounding real-time road network information from OpenDrive and apply in driving decision;The application comprises the following steps: S1, obtaining global static information of map, including all road points and pedestrian crossings;S2, all road points around the vehicle are obtained using KD-Tree;S3, according to the content to be described and the attribute value of road point, generate natural language description of drivable road network.The application effectively improves the accuracy and reliability of driving decision, generates complete and reliable natural language description of drivable road network around the vehicle, and can be applied to generate road network information in natural language form.

Description

TECHNICAL FIELD

[0001] The application relates to a natural language description method, in particular to a natural language description method of a drivable road network based on road points, and belongs to the technical field of traffic simulation based on deep learning. BACKGROUND

[0002] In recent years, with the rapid development of LLM (Large Language Model), LLM has been widely applied in various task scenarios. In addition to traditional translation, question answering and text generation, more and more researchers have begun to focus on the language understanding and logical reasoning capabilities of LLM and have tried to apply LLM to tasks that require high human-like level, one of which is automatic driving. The previous automatic driving algorithm is based on image data, laser radar point cloud data and vehicle trajectory data to make driving decisions, which is called data-driven automatic driving. After the emergence of LLM, some researchers have begun to use it for automatic driving decisions, that is, to provide LLM with a description of the driving scene, to imitate human thinking and make decisions by using the reasoning ability of LLM to achieve a more human-like and more explainable automatic driving system. Since the training data of LLM is mostly various forms of human knowledge corpus, the basis for reasoning is also the human knowledge accumulated in the training process, therefore, this kind of automatic driving system using LLM for driving decision is also called knowledge-driven automatic driving.

[0003] Since the core of knowledge-driven automatic driving is LLM, the main directions for optimizing its performance are as follows: one is to improve the reasoning ability and decision accuracy of the model; the other is to perform prompt engineering, that is, to design and optimize the input prompts for LLM to improve the quality and accuracy of the output. Common methods include information supplementing, explicit instruction and thinking chain. From the perspective of prompt engineering, the prompts input to LLM in the current mainstream knowledge-driven automatic driving system include vehicles and pedestrians around the host vehicle, traffic signals in front, and optional driving instructions, which are sufficient to make driving decisions, but still lack information completeness.

[0004] In the prior art, the automation and measurement systems standardization association (ASAM) proposes a road network description standard named OpenDrive, which uses extensible markup language (XML) to define detailed information of a road, including lanes, intersections, traffic signs, road surface types, etc., and provides a standard and accurate road network description method, so that road network data can be shared and exchanged between different systems and platforms; although OpenDrive can completely and accurately describe a road network, it cannot be directly used as a prompt input for LLM, first, the XML file of OpenDrive is often too long, and only describing the road network of a single small town requires tens of thousands of lines, and a larger file content will cause LLM to be difficult to parse; second, since XML is not a natural language, LLM is also difficult to understand the content described by OpenDrive; finally, OpenDrive is a complete description of the road network in the entire map range, and does not contain the position information of the vehicle, which means that the position of the vehicle and the real-time road network information around it cannot be obtained directly from OpenDrive, so it cannot be used for road network description in driving decision.

[0005] In summary, a natural language description method of drivable road network based on road points is needed. SUMMARY

[0006] A brief summary of the application is given below in order to provide a basic understanding of some aspects of the application. It should be understood that this summary is not an exhaustive overview of the application. It is not intended to identify key or important parts of the application nor is it intended to limit the scope of the application. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is discussed later.

[0007] In view of this, in order to solve the problem that the traditional road network description method in the prior art cannot directly obtain the position of the vehicle and the real-time road network information around it from OpenDrive and apply it to driving decision, the application provides a natural language description method of drivable road network based on road points.

[0008] The technical solution is as follows: a natural language description method of drivable road network based on road points, comprising the following steps:

[0009] S1. Obtain global static information of the map, including all road points and pedestrian crossings;

[0010] S2. Obtain all road points around the vehicle using KD-Tree;

[0011] S3. Generate a natural language description of the drivable road network according to the content to be described and the attribute values of the road points.

[0012] Further, in S1, the road points and crosswalk information contained in the CARLA map are collected, and the specific process is as follows:

[0013] S11. The user obtains all road points in the CARLA map at a set interval through the API provided by the CARLA map, and saves them as a road point list. At the same time, the coordinates of each road point are extracted to construct a road point coordinate array for subsequent initialization of the KD-Tree.

[0014] S12. The user separately obtains all crosswalks through the API provided by the CARLA map for subsequent description of the crosswalks.

[0015] Further, in S2, the KD-Tree is initialized using the road point coordinate array, the query_ball_point() function is called to obtain the indices of road points within a set radius, and then all road points around the vehicle are obtained from the road point list according to the indices.

[0016] Further, in S3, the contents to be described include the vehicle position, the number of lanes and the lane in which the vehicle is located, the lane width, the lane-changing behavior allowed in the lane where the vehicle is located, whether there is an intersection ahead and the distance to the intersection, whether there is a crosswalk ahead and the distance to the crosswalk, and the specific generation process is as follows:

[0017] S31. According to the CARLA map, the vehicle object coordinates are embedded into a string to describe the vehicle position, and the description format is as follows: “You are driving at ({x-axis coordinate of the vehicle}, {y-axis coordinate of the vehicle}, {z-axis coordinate of the vehicle}), and the surrounding road network is illustrated as follows.”;

[0018] S32. According to the vehicle position, the lane ID in which the vehicle is located is directly described, and the number of lanes in the direction in which the vehicle is traveling is calculated and described through the LLM;

[0019] S33. The lane width of the current road is directly described using the lane width attribute value of the road point where the vehicle is located, and the description format is as follows: “And the width of lanes of the current road is {lane width}.”;

[0020] S34. According to the possible lane-changing behavior, the lane-changing behavior allowed in the lane where the vehicle is located is described.

[0021] S35. Starting from the current road point where the vehicle is located, iteratively obtain the road points in front until one of the following conditions is met: the road point is at an intersection or the distance and description radius are the same, and describe whether there is an intersection in front and the distance to the intersection;

[0022] S36. According to the vehicle position information in the CARLA map, describe whether there is a pedestrian crossing in front and the distance to the pedestrian crossing;

[0023] In the S32, the following steps are included:

[0024] S321. Obtain the road point corresponding to the vehicle position, and determine whether it exists. If it does not exist, describe the error information and end the description;

[0025] S322. According to the lane attribute value of the road point corresponding to the vehicle position, determine whether the lane where the vehicle is located is drivable. If it is not drivable, describe the error information and end the description;

[0026] S323. Select a road point in the vehicle's periphery and determine whether it has the same road ID and lane ID symbol as the current road point corresponding to the vehicle. Add the lane ID of the road point with the same road ID and lane ID symbol to the lane ID set;

[0027] S324. Repeat steps S323 and S324 until all road points in the vehicle's periphery have been traversed;

[0028] S325. Calculate the number of elements in the lane ID set, and the result is the number of lanes in the direction the vehicle is driving;

[0029] S326. Describe the number of lanes and the lane where the vehicle is located in the format: "There are {number of lane IDs} lanes in the direction you are driving. You are driving on the lane with ID {lane ID where the vehicle is located} (lane IDs start from 1 or -1. Generally, the smaller the absolute value of the lane ID, the closer the lane is to the road centerline; the larger the absolute value of the lane ID, the farther the lane is from the road centerline).";

[0030] In S34, possible lane-changing behaviors include not allowing lane changes, allowing right lane changes but not allowing left lane changes, allowing left lane changes but not allowing right lane changes, and allowing either left or right lane changes.

[0031] The description format for disallowing lane changes is: "In addition, the current lane does not allow turning right or left, only going straight."

[0032] The description format for allowing lane changes to the right but not the left is: "In addition, the current lane allows turning right, but does not allow turning left."

[0033] The description format for allowing lane changes to the left but not the right is: "In addition, the current lane allows turning left, but does not allow turning right."

[0034] The description format for allowing lane changes to the left or right is: "In addition, the current lane allows turning either right or left."

[0035] In S35, when a road point is at an intersection, the distance between the vehicle's current road point and the road point is further calculated, and the intersection is described in the following format: "Finally, there is a junction ahead and the distance to the junction is {distance from the intersection} meters."

[0036] When the iterated distance and the described radius are the same, it indicates that there is no intersection ahead, described as: "Finally, there is no junction ahead."

[0037] S36 includes the following steps:

[0038] S361. Use the Point module in the Python.shapely.geometry library to represent the vehicle's current position as a two-dimensional point, initialize the marker for whether there is a pedestrian crossing ahead to no, and initialize the distance from the vehicle to the pedestrian crossing to infinity;

[0039] S362. Select a pedestrian crossing and use the Polygon module in the Python.shapely.geometry library to represent the pedestrian crossing as a two-dimensional polygon by combining the positions of the four vertices of the pedestrian crossing.

[0040] S363. Calculate the distance from the vehicle to the pedestrian crossing boundary and determine whether the pedestrian crossing is within the described range;

[0041] S364. If the pedestrian crossing is within the described range, calculate the dot product of the vehicle direction vector and the pedestrian crossing center point direction vector to determine whether the pedestrian crossing is in front of the vehicle and whether it is within the described range in front. If the pedestrian crossing is not within the angle of the described range in front, proceed to step S362.

[0042] S365. If the pedestrian crossing is within the angle of the described range ahead, update the value of the flag indicating whether there is a pedestrian crossing ahead to "yes", and further compare the existing distance from the vehicle to the pedestrian crossing with the distance from the vehicle to the current pedestrian crossing. Take the expected value of the two to update the distance from the vehicle to the pedestrian crossing, and obtain the distance from the vehicle to the nearest pedestrian crossing.

[0043] S366. Repeat steps S362 to S365 until all pedestrian crossings have been traversed;

[0044] S367. If there is a crosswalk ahead, describe the distance from the vehicle to the crosswalk in the format: "Please note that there is a crosswalk ahead of you, the distance to the crosswalk is {distance from the vehicle to the crosswalk} meters." If there is no crosswalk ahead, no additional description is required.

[0045] The beneficial effects of this invention are as follows: Based on the characteristics of LLM in knowledge-driven autonomous driving systems, which mimics the reasoning process of human drivers in making driving decisions, and the observation process of human drivers during driving, this invention provides a method for generating a natural language description of the drivable road network for an autonomous driving master vehicle in the CARLA traffic simulation platform, relying on waypoints. This method provides road network information in natural language form for knowledge-driven autonomous driving agents operating on CARLA, thus compensating for the lack of road network information in existing knowledge-driven autonomous driving decision-making. This invention utilizes the waypoint mechanism, combined with the range query capability of KD-Tree, to quickly obtain road network information around the vehicle and quickly retrieve waypoints around the autonomous driving master vehicle. It also designs a system for automatically... This invention uses a natural language template and the information contained in waypoints to generate a complete and reliable natural language description of the drivable road network around the vehicle. This supplements LLM with road spatial information to obtain more accurate driving decisions, improve the performance of knowledge-driven autonomous driving systems, and enhance the accuracy and reliability of decisions, thereby achieving more realistic, safer, and more human-like driving decisions. The road network information provided by this invention includes vehicle position, number of lanes and the lane the vehicle is in, lane width, permitted lane changing behavior in the lane the vehicle is in, whether there is an intersection ahead and the distance to the intersection, and whether there is a pedestrian crossing ahead and the distance to the pedestrian crossing. This can cover the road network information required for driving decisions and meet the information needs of LLMs that rely on human-like reasoning for driving decisions. Attached Figure Description

[0046] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0047] Figure 1 This is a flowchart illustrating a natural language description method for a waypoint-based drivable road network.

[0048] Figure 2 This is a schematic flowchart of an embodiment of a natural language description method for a waypoint-based drivable road network. Detailed Implementation

[0049] To make the technical solutions and advantages of the embodiments of the present invention clearer, the exemplary embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0050] refer to Figure 1 and Figure 2This embodiment describes a natural language description method for drivable road networks based on waypoints, specifically including the following steps:

[0051] S1. Obtain global static information of the map, including all waypoints and pedestrian crossings;

[0052] S2. Based on the global static information of the map, use KD-Tree to obtain all waypoints around the vehicle;

[0053] S3. Generate a natural language description of the drivable road network based on the content to be described and the attribute values ​​of waypoints.

[0054] Furthermore, in step S1, in order to generate a natural language description of the drivable road network around the vehicle, waypoint and pedestrian crossing information contained in the CARLA map is collected. The specific process is as follows:

[0055] S11. Waypoints in the CARLA map are predefined in the road network. Users can obtain all waypoints in the CARLA map at set intervals through the API (Application Programming Interface) provided by the CARLA map and save them as a waypoint list. At the same time as obtaining the waypoints, the coordinates of each waypoint are extracted and a Python.numpy array of waypoint coordinates is constructed for subsequent initialization of KD-Tree.

[0056] S12. Since waypoints do not contain information about pedestrian crossings, users need to obtain all pedestrian crossings separately through the API provided by CARLA Maps for subsequent descriptions of pedestrian crossings.

[0057] Furthermore, in S2, the KD-Tree is initialized using a waypoint coordinate array, the query_ball_point() function is called to obtain the index of the waypoint within a set radius range (called the description radius), and then all waypoints within a set range around the vehicle are obtained from the waypoint list according to the index.

[0058] Specifically, the KD-Tree and query_ball_point() functions (used to find all points within a specified radius) are called through the Python.scipy.spatial library (a module specifically for spatial calculations and computational geometry-related operations) to perform range queries.

[0059] Furthermore, in S3, the content to be described includes vehicle position, number of lanes and the lane the vehicle is in, lane width, lane-changing behavior allowed in the lane the vehicle is in, whether there is an intersection ahead and the distance to the intersection, and whether there is a pedestrian crossing ahead and the distance to the pedestrian crossing. The specific generation process is as follows:

[0060] S31. According to the CARLA map, since the vehicle objects in the CARLA map themselves have three-dimensional spatial coordinate values, the vehicle object coordinates are directly embedded into the string to describe the vehicle's position. The description format is: "You are driving at ({vehicle's x-axis coordinate}, {vehicle's y-axis coordinate}, {vehicle's z-axis coordinate}), and the surroudingroad network is illustrated as follows."

[0061] S32. Based on the vehicle's location, since each waypoint has a road ID and lane ID attribute, the lane ID where the vehicle is located can be directly described (in order for the LLM (Large Language Model) to understand the relative position of the lane, additional explanation is needed: the lane ID starts from 1 or -1. Generally speaking, the smaller the absolute value of the lane ID, the closer it is to the center line of the road, and vice versa). The number of lanes in the direction the vehicle is traveling (i.e., the direction of travel) is calculated and described by the LLM.

[0062] S33. Directly use the lane width attribute value of the road point where the vehicle is located to describe the lane width of the current road (assuming that all lanes have the same width). The description format is: "And the width of lanes of the current road is {lane width}.";

[0063] S34. The lane change attribute of a waypoint defines the lane change behavior allowed at the location of the waypoint. Essentially, it describes whether the left and right sides of the lane are solid lines (no lane change allowed) or dashed lines (lane change allowed). Based on the possible lane change behaviors, it describes the lane change behavior allowed for the vehicle in its lane.

[0064] S35. To determine whether there is an intersection ahead of the vehicle, simply start from the current road point of the vehicle and iterate forward to obtain road points until one of the following situations is encountered: a road point is located at an intersection or the iterated distance is the same as the description radius. Then describe whether there is an intersection ahead and the distance to the intersection.

[0065] S36. Since pedestrian crossings in the CARLA map are represented by the positions of their four vertices, the location and detection of pedestrian crossings are relatively complex. Based on the vehicle position information in the CARLA map, describe whether there is a pedestrian crossing ahead and the distance to the pedestrian crossing.

[0066] S32 includes the following steps:

[0067] S321. Obtain the waypoint corresponding to the vehicle's location and determine if it exists. If it does not exist, describe the error message and end the description.

[0068] S322. Based on the lane attribute value of the road point corresponding to the vehicle's location, determine whether the lane in which the vehicle is located is drivable. If it is not drivable, describe the error message and end the description.

[0069] S323. Select a road point located near the vehicle and determine if it has the same road ID and lane ID symbol as the current road point corresponding to the vehicle (if the symbols are the same, they are in the same direction; otherwise, they are in opposite directions); add the lane IDs of road points with the same road ID and lane ID symbol to the Python lane ID set (the elements in the set are unique).

[0070] S324. Repeat steps S323 and S324 until all waypoints around the vehicle have been traversed;

[0071] S325. Calculate the number of elements in the lane ID set. The result is the number of lanes in the direction the vehicle is traveling.

[0072] S326. Describe the number of lanes and the lane your vehicle is in using the following format: "There are {lane IDs} lanes in the direction you are driving. You are driving on the lane with ID {vehicle's lane ID} (lane IDs start from 1 or -1. Generally, the smaller the absolute value of the lane ID, the closer the lane is to the road centerline; the larger the absolute value of the lane ID, the farther the lane is from the road centerline)."

[0073] In S34, possible lane-changing behaviors include not allowing lane changes, allowing right lane changes but not allowing left lane changes, allowing left lane changes but not allowing right lane changes, and allowing either left or right lane changes.

[0074] The description format for disallowing lane changes is: "In addition, the current lane does not allow turning right or left, only going straight."

[0075] The description format for allowing lane changes to the right but not the left is: "In addition, the current lane allows turning right, but does not allow turning left."

[0076] The description format for allowing lane changes to the left but not the right is: "In addition, the current lane allows turning left, but does not allow turning right."

[0077] The description format for allowing lane changes to the left or right is: "In addition, the current lane allows turning either right or left."

[0078] In S35, when a road point is at an intersection, the distance between the vehicle's current road point and the road point is further calculated, and the intersection is described in the following format: "Finally, there is a junction ahead and the distance to the junction is {distance from the intersection} meters."

[0079] When the iterated distance and the described radius are the same, it indicates that there is no intersection ahead, described as: "Finally, there is no junction ahead."

[0080] S36 includes the following steps:

[0081] S361. Use the Point module (used to represent points in a two-dimensional plane) in the Python.shapely.geometry library (a library for processing two-dimensional planar geometric objects) to represent the vehicle's current position as a two-dimensional point, initialize the marker for whether there is a pedestrian crossing ahead to no, and initialize the distance from the vehicle to the pedestrian crossing to infinity;

[0082] S362. Select a pedestrian crossing and use the Polygon module (the core class for representing two-dimensional polygons) in the Python.shapely.geometry library to represent the pedestrian crossing as a two-dimensional polygon by combining the positions of the four vertices of the pedestrian crossing (to simplify the process, the z-axis coordinate is ignored, that is, it is assumed that the vehicle and the pedestrian crossing are on a two-dimensional plane).

[0083] S363. Calculate the distance from the vehicle to the pedestrian crossing boundary and determine whether the pedestrian crossing is within the described range;

[0084] S364. If the pedestrian crossing is within the described range, calculate the dot product of the vehicle direction vector and the pedestrian crossing center point direction vector to determine whether the pedestrian crossing is in front of the vehicle and whether it is within the described range in front. If the pedestrian crossing is not within the angle of the described range in front, proceed to step S362.

[0085] S365. If the pedestrian crossing is within the angle of the described range ahead, update the value of the marker indicating whether there is a pedestrian crossing ahead to "yes", and further compare the existing distance from the vehicle to the pedestrian crossing with the distance from the vehicle to the current pedestrian crossing. Take the smaller of the two expected values ​​to update the distance from the vehicle to the pedestrian crossing, and obtain the distance from the vehicle to the nearest pedestrian crossing.

[0086] S366. Repeat steps S362 to S365 until all pedestrian crossings have been traversed;

[0087] S367. If there is a crosswalk ahead, describe the distance from the vehicle to the crosswalk in the format: "Please note that there is a crosswalk ahead of you, the distance to the crosswalk is {distance from the vehicle to the crosswalk} meters." If there is no crosswalk ahead, no additional description is required.

[0088] Specifically, CARLA (Car Learning to Act) is an open-source autonomous driving simulation platform designed to provide a highly realistic virtual environment for autonomous driving research, development, and testing. CARLA offers a variety of scenarios, weather conditions, traffic patterns, road networks, and complex environmental settings for researchers to test autonomous driving systems and algorithms.

[0089] A road network is a transportation network consisting of a series of roads, intersections, lanes, etc. It not only covers basic road connections, but also includes elements such as traffic signals, signs, and road condition information. In autonomous driving and intelligent transportation systems, road networks can provide detailed geometric information, lane divisions, traffic signs, traffic flow directions, etc., which helps to improve the vehicle's positioning accuracy and path planning capabilities.

[0090] A waypoint is a node in the CARLA road network with specific locations and attributes, used to describe the network's topology. Each road network contains geometric information about the roads it occupies, such as 3D coordinates, orientation, road and lane IDs, lane attributes, and road segment types. Through a series of ordered waypoints, CARLA can create complete road paths for autonomous driving simulation systems to perform path planning, localization, and navigation.

[0091] A K-Dimensional Tree (KD-Tree) is a tree-structured data structure used for fast retrieval of multidimensional spatial data. It is often used to handle problems such as spatial partitioning, nearest neighbor search, and range queries. KD-Tree divides data points into sub-regions according to dimensions, thereby improving the efficiency of performing search operations in high-dimensional space.

[0092] Large Language Models (LLMs) are deep learning models capable of processing natural language data. They can perform various tasks based on task descriptions in natural language form, such as text generation, question answering, translation, and summarization. Large Language Models are considered to possess human-like language understanding and logical reasoning abilities, enabling them to think, reason, and make decisions in a manner similar to humans, based on knowledge accumulated during training.

[0093] A prompt is a text description or instruction given to an LLM to guide it in generating specific outputs and completing a task. A prompt can be a question, a description, a command, or any form of input. The LLM is able to understand the intent of the task based on the input and generate the corresponding answer or content.

[0094] Although the invention has been described with reference to a limited number of embodiments, those skilled in the art will understand from the foregoing description that other embodiments are conceivable within the scope of the invention described herein. Furthermore, it should be noted that the language used in this specification has been chosen primarily for readability and instructional purposes, and not for the purpose of interpreting or limiting the subject matter of the invention. Therefore, many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the appended claims. The disclosure of the invention is illustrative and not restrictive, and the scope of the invention is defined by the appended claims.

Claims

1. A natural language description method for drivable road networks based on waypoints, characterized in that, Includes the following steps: S1. Obtain global static information of the map, including all waypoints and pedestrian crossings; S2. Use KD-Tree to obtain all waypoints around the vehicle; S3. Generate a natural language description of the drivable road network based on the content to be described and the attribute values ​​of waypoints; In S2, the KD-Tree is initialized using a waypoint coordinate array, the query_ball_point() function is called to obtain the index of the waypoint within a set radius, and then all waypoints around the vehicle are obtained from the waypoint list based on the index. In S3, the content to be described includes vehicle position, number of lanes and the lane the vehicle is in, lane width, lane changing behavior allowed in the lane the vehicle is in, whether there is an intersection ahead and the distance to the intersection, and whether there is a pedestrian crossing ahead and the distance to the pedestrian crossing. The specific generation process is as follows: S31. Based on the CARLA map, embed the vehicle object coordinates into a string to describe the vehicle's location; S32. Based on the vehicle's location, directly describe the lane ID where the vehicle is located, and calculate and describe the number of lanes in the direction the vehicle is traveling using LLM; S33. Directly use the lane width attribute value of the road point where the vehicle is located to describe the lane width of the current road; S34. Based on possible lane-changing behaviors, describe the lane-changing behaviors permitted in the lane where the vehicle is located; S35. Starting from the current waypoint of the vehicle, continuously iterate forward to obtain waypoints until a waypoint is encountered at an intersection or the iterated distance is the same as the description radius. Describe whether there is an intersection ahead and the distance to the intersection. S36. Based on the vehicle location information in the CARLA map, describe whether there is a pedestrian crossing ahead and the distance to the pedestrian crossing; S32 includes the following steps: S321. Obtain the waypoint corresponding to the vehicle's location and determine if it exists. If it does not exist, describe the error message and end the description. S322. Based on the lane attribute value of the road point corresponding to the vehicle's location, determine whether the lane in which the vehicle is located is drivable. If it is not drivable, describe the error message and end the description. S323. Select a road point located around the vehicle and determine whether it has the same road ID and lane ID symbol as the current road point corresponding to the vehicle; add the lane IDs of road points with the same road ID and lane ID symbol to the lane ID set; S324. Repeat steps S323 and S324 until all waypoints around the vehicle have been traversed; S325. Calculate the number of elements in the lane ID set. The result is the number of lanes in the direction the vehicle is traveling. S326. Describe the number of lanes and the lane the vehicle is in according to the specified format; In S34, possible lane-changing behaviors include not allowing lane changes, allowing right lane changes but not allowing left lane changes, allowing left lane changes but not allowing right lane changes, and allowing either left or right lane changes. In S35, when a road point is at an intersection, the distance between the vehicle's current road point and the road point is further calculated, and the intersection is described. When the iterated distance and the description radius are the same, it indicates that there are no intersections ahead; S36 includes the following steps: S361. Use the Point module in the Python.shapely.geometry library to represent the vehicle's current position as a two-dimensional point, initialize the marker for whether there is a pedestrian crossing ahead to no, and initialize the distance from the vehicle to the pedestrian crossing to infinity; S362. Select a pedestrian crossing and use the Polygon module in the Python.shapely.geometry library to represent the pedestrian crossing as a two-dimensional polygon by combining the positions of the four vertices of the pedestrian crossing. S363. Calculate the distance from the vehicle to the pedestrian crossing boundary and determine whether the pedestrian crossing is within the described range; S364. If the pedestrian crossing is within the described range, calculate the dot product of the vehicle direction vector and the pedestrian crossing center point direction vector to determine whether the pedestrian crossing is in front of the vehicle and whether it is within the described range in front. If the pedestrian crossing is not within the angle of the described range in front, proceed to step S362. S365. If the pedestrian crossing is within the angle of the described range ahead, update the value of the flag indicating whether there is a pedestrian crossing ahead to "yes", and further compare the existing distance from the vehicle to the pedestrian crossing with the distance from the vehicle to the current pedestrian crossing. Take the expected value of the two to update the distance from the vehicle to the pedestrian crossing, and obtain the distance from the vehicle to the nearest pedestrian crossing. S366. Repeat steps S362 to S365 until all pedestrian crossings have been traversed; S367. If there is a pedestrian crossing ahead, describe the distance from the vehicle to the pedestrian crossing; if there is no pedestrian crossing ahead, do not provide any additional description.

2. The natural language description method for a waypoint-based drivable road network according to claim 1, characterized in that, In step S1, waypoint and pedestrian crossing information contained in the CARLA map is collected. The specific process is as follows: S11. Users obtain all waypoints in the CARLA map at set intervals through the API provided by the CARLA map and save them as a waypoint list. At the same time as obtaining the waypoints, the coordinates of each waypoint are extracted and a waypoint coordinate array is constructed for subsequent initialization of KD-Tree. S12. Users can obtain all pedestrian crossings individually through the API provided by CARLA Maps for subsequent descriptions of pedestrian crossings.

Images