Parking planning method and device

Abstract

The application provides a parking planning method and device, and relates to the field of intelligent vehicle control and intelligent parking. The method comprises the following steps: acquiring a full information data set of a parking lot, wherein the full information data set comprises static topological information and dynamic real-time information; determining running state information in the parking lot according to the static topological information and the dynamic real-time information; receiving a service request sent by a vehicle-side controller, and sending the static topological information to the vehicle-side controller according to the service request; receiving a decision assistance request sent by the vehicle-side controller, and sending the running state information to the vehicle-side controller at a preset period according to the decision assistance request, so that the vehicle-side controller generates a candidate path according to the static topological information and the running state information, determines a target path, and controls the vehicle to perform a parking action based on the target path. The method provided by the application improves the completeness and timeliness of the acquired environmental information, and improves the path planning accuracy, the parking success rate and the traffic efficiency.

Description

Technical Field

[0001] This application relates to the fields of intelligent vehicle control and intelligent parking, and in particular to a parking planning method and device. Background Technology

[0002] Current advanced parking systems mostly use onboard sensors combined with pre-collected maps to achieve autonomous navigation and parking control within parking lots.

[0003] However, this type of method is limited by the perception range of a single vehicle and occupancy conditions, making it difficult to obtain the overall dynamic status of the parking lot. It also lacks sufficient ability to identify low obstacles, obstructed areas, and real-time changes in parking space occupancy. Furthermore, the pre-collected map updates are delayed, which can cause the path planning results to deviate from the actual scene, thus affecting parking efficiency, traffic safety, and system reliability.

[0004] Therefore, how to improve the completeness and timeliness of environmental information acquisition in complex parking lot dynamic environments, so as to improve the accuracy and reliability of parking route planning, is a technical problem that needs to be solved. Summary of the Invention

[0005] This application provides a parking planning method and device to solve the aforementioned technical problems. This solution addresses the parking business needs in dynamic parking environments by comprehensively utilizing parking environment information and vehicle-side service interaction mechanisms to uniformly acquire, determine, and collaboratively support information related to parking decisions within the parking lot. This provides a more comprehensive and timely information foundation for path generation and selection during vehicle parking, improving the accuracy and reliability of parking planning in complex scenarios.

[0006] Firstly, this application provides a parking planning method, which includes:

[0007] Obtain the full information dataset of the parking lot, which includes static topology information and dynamic real-time information;

[0008] Based on static topology information and dynamic real-time information, the operational status information within the parking lot is determined;

[0009] Receive service requests sent by the vehicle controller and send static topology information to the vehicle controller according to the service requests;

[0010] The system receives decision assistance requests from the vehicle controller and sends operating status information to the vehicle controller at preset intervals based on the decision assistance requests, so that the vehicle controller can generate candidate paths and determine target paths based on static topology information and operating status information, and control the vehicle to perform parking actions based on the target paths.

[0011] In one possible implementation, determining the operational status information within the parking lot includes:

[0012] Construct a topological map of the parking lot based on static topological information;

[0013] Dynamic real-time information is mapped onto the topology map, and a real-time global situation map of the field is generated through spatiotemporal alignment, which serves as operational status information.

[0014] In one possible implementation, sending static topology information includes:

[0015] Parse the service request to obtain vehicle size parameters;

[0016] Filter out passable areas and available parking spaces that meet the vehicle size parameters from static topology information;

[0017] The filtered static topology information is sent to the vehicle-side controller.

[0018] Secondly, this application provides a parking planning method, which includes:

[0019] In response to a parking request initiated by a user, a service request containing vehicle size parameters is sent to the parking lot.

[0020] Receive static topology information sent by the field end in response to the service request;

[0021] Send a decision support request to the parking lot and receive operation status information sent by the parking lot in response to the decision support request at a preset period. The operation status information is determined by the parking lot based on the full information dataset of the parking lot. The full information dataset includes static topology information and dynamic real-time information.

[0022] Multiple candidate paths are generated based on static topology information and operational status information;

[0023] A comprehensive analysis of multiple candidate paths is conducted to determine the target path;

[0024] Based on the target path, control the vehicle to perform a parking action.

[0025] In one possible implementation, controlling the vehicle to perform a parking action includes:

[0026] Acquire local perception data collected by vehicle-mounted sensors;

[0027] Local sensing data is fused with operational status information to generate fused environmental information;

[0028] Based on the integrated environmental information and target path, the system controls the vehicle to perform parking actions.

[0029] In one possible implementation, controlling the vehicle to perform a parking action further includes:

[0030] Based on the integrated environmental information, local dynamic obstacle avoidance planning is performed on the target path to generate a target path containing local obstacle avoidance trajectories.

[0031] Based on the target path that includes a partial obstacle avoidance trajectory, control the vehicle to perform a parking maneuver.

[0032] In one possible implementation, determining the target path includes:

[0033] Acquire user historical behavior data and site service resource information;

[0034] Based on user historical behavior data and on-site service resource information, multiple candidate paths are scored;

[0035] The candidate path with the highest score is selected as the target path.

[0036] In one possible implementation, the method further includes:

[0037] While the vehicle is traveling along the target path, monitor the changes in the information of the site-side service resources.

[0038] When the changing state matches the available resources at the site with the service resources predicted based on the user's historical service list, service recommendation information is generated.

[0039] Service recommendations are displayed to users through the in-vehicle interactive terminal.

[0040] In one possible implementation, after displaying service recommendation information to the user via the in-vehicle interactive terminal, the process further includes:

[0041] In response to the user's confirmation of the service recommendation information, a service reservation request is generated;

[0042] Send the service reservation request to the site.

[0043] Thirdly, embodiments of this application provide a parking planning device, the device comprising:

[0044] The first acquisition module is used to acquire the full information dataset of the parking lot, which includes static topology information and dynamic real-time information.

[0045] The determination module is used to determine the operating status information within the parking lot based on static topology information and dynamic real-time information;

[0046] The first sending module is used to receive service requests sent by the vehicle controller and send static topology information to the vehicle controller according to the service requests.

[0047] The second sending module is used to receive decision assistance requests sent by the vehicle controller, and according to the decision assistance requests, send operation status information to the vehicle controller at a preset period, so that the vehicle controller can generate candidate paths and determine target paths based on static topology information and operation status information, and control the vehicle to perform parking actions based on the target paths.

[0048] In one possible implementation, the determining module is specifically used for:

[0049] Construct a topological map of the parking lot based on static topological information;

[0050] Dynamic real-time information is mapped onto the topology map, and a real-time global situation map of the field is generated through spatiotemporal alignment, which serves as operational status information.

[0051] In one possible implementation, the first transmitting module is specifically used for:

[0052] Parse the service request to obtain vehicle size parameters;

[0053] Filter out passable areas and available parking spaces that meet the vehicle size parameters from static topology information;

[0054] The filtered static topology information is sent to the vehicle-side controller.

[0055] Fourthly, this application provides a parking planning device, the device comprising:

[0056] The third sending module is used to respond to a parking request initiated by a user by sending a service request containing vehicle size parameters to the parking lot.

[0057] The first receiving module is used to receive static topology information sent by the field end in response to the service request;

[0058] The second receiving module is used to send a decision assistance request to the site and receive the operation status information sent by the site in response to the decision assistance request at a preset period. The operation status information is determined by the site based on the full information dataset of the parking lot. The full information dataset includes static topology information and dynamic real-time information.

[0059] The generation module is used to generate multiple candidate paths based on static topology information and runtime status information;

[0060] The analysis module is used to comprehensively analyze multiple candidate paths to determine the target path;

[0061] The control module is used to control the vehicle to perform parking actions based on the target path.

[0062] In one possible implementation, the control module is specifically used for:

[0063] Acquire local perception data collected by vehicle-mounted sensors;

[0064] Local sensing data is fused with operational status information to generate fused environmental information;

[0065] Based on the integrated environmental information and target path, the system controls the vehicle to perform parking actions.

[0066] In one possible implementation, the control module is further configured to:

[0067] Based on the integrated environmental information, local dynamic obstacle avoidance planning is performed on the target path to generate a target path containing local obstacle avoidance trajectories.

[0068] Based on the target path that includes a partial obstacle avoidance trajectory, control the vehicle to perform a parking maneuver.

[0069] In one possible implementation, the analysis module is specifically used for:

[0070] Acquire user historical behavior data and site service resource information;

[0071] Based on user historical behavior data and on-site service resource information, multiple candidate paths are scored;

[0072] The candidate path with the highest score is selected as the target path.

[0073] In one possible implementation, the control module is further configured to:

[0074] While the vehicle is traveling along the target path, monitor the changes in the information of the site-side service resources.

[0075] When the changing state matches the available resources at the site with the service resources predicted based on the user's historical service list, service recommendation information is generated.

[0076] Service recommendations are displayed to users through the in-vehicle interactive terminal.

[0077] In one possible implementation, the control module is further configured to:

[0078] In response to the user's confirmation of the service recommendation information, a service reservation request is generated;

[0079] Send the service reservation request to the site.

[0080] Fifthly, embodiments of this application provide a parking planning device, including: a processor and a memory;

[0081] The memory stores instructions that the computer executes;

[0082] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method provided in the first aspect of the invention, or to perform the method provided in the second aspect of the invention.

[0083] In a sixth aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement a parking planning method according to the first aspect of the invention or a parking planning method according to the second aspect of the invention.

[0084] In a seventh aspect, this application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a parking planning method according to the first aspect of the invention or a parking planning method according to the second aspect of the invention.

[0085] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0086] This application provides a parking planning method and device that, by acquiring a complete dataset of parking lot information and determining the parking lot's operational status information based on static topology information and dynamic real-time information, can provide the vehicle-side controller with parking decision-making basis that takes into account both site structural characteristics and real-time environmental changes. Furthermore, by responding to service requests by sending static topology information and responding to decision support requests by sending operational status information at preset intervals, the vehicle-side controller can generate candidate paths, determine target paths, and control vehicles to perform parking actions. This improves the accuracy, timeliness, and reliability of path planning in complex parking lot dynamic environments, thereby enhancing parking efficiency and traffic safety. Attached Figure Description

[0087] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0088] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0089] Figure 1 A schematic diagram illustrating the application scenario of the parking planning method provided in this application;

[0090] Figure 2 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 1 ;

[0091] Figure 3 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 2 ;

[0092] Figure 4 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 3 ;

[0093] Figure 5 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 4 ;

[0094] Figure 6 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 5 ;

[0095] Figure 7 A schematic diagram of the structure of a parking planning device provided in this application embodiment. Figure 1 ;

[0096] Figure 8 A schematic diagram of the structure of a parking planning device provided in this application embodiment. Figure 2 ;

[0097] Figure 9 This is a schematic diagram of a parking planning device provided in an embodiment of this application. Detailed Implementation

[0098] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0099] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being better or more advantageous than other embodiments or design schemes. Specifically, the use of "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0100] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the parking planning method provided in the embodiments of this application is merely an example; a parking planning method may include more or fewer elements.

[0101] This application relates to the field of intelligent parking and autonomous vehicle navigation control technology, and is particularly applicable to parking environments with complex structures, dense parking spaces, and continuously changing traffic conditions, such as commercial complexes, hospitals, and office buildings. The relevant system typically consists of a vehicle-mounted controller, an onboard sensing unit, and a parking information management system working together to complete path planning, parking space arrival, and parking control within the parking lot.

[0102] Existing advanced parking solutions typically work by combining onboard sensor perception with pre-collected maps. That is, after the vehicle enters the parking lot, it uses cameras, lidar, or ultrasonic sensors to obtain local environmental information and combines it with a pre-stored parking lot map to perform route planning and parking decisions.

[0103] This type of method mainly relies on real-time perception within a limited area around the vehicle, making it difficult to grasp the overall dynamic status of the parking lot, such as parking space occupancy, traffic flow changes, temporary obstacles, and obstructed areas. When there are low obstacles, obstructed views, temporary road adjustments, or rapid changes in parking space status, the information relied upon by the vehicle-side controller is prone to being incomplete or inaccurate.

[0104] Meanwhile, pre-collected maps typically focus on reflecting the static structure of parking lots, have long update cycles, and struggle to match real-time changes in the actual operating environment. This can easily lead to deviations between planned driving routes and the actual conditions. These shortcomings not only reduce the accuracy of route planning but may also cause detours, traffic congestion, parking failures, and even safety risks, thereby affecting system reliability and user experience.

[0105] Therefore, how to improve the completeness and timeliness of environmental information acquisition in complex parking lot dynamic environments, and enable vehicle-side controllers to implement parking planning based on more accurate parking lot conditions, has become an urgent technical problem to be solved.

[0106] Based on this, this application proposes a parking planning method that can be used in the fields of intelligent vehicle control and intelligent parking, aiming to solve the above-mentioned technical problems of the prior art. It obtains a full data set containing static topology information and dynamic real-time information, and determines the operating status information within the parking lot accordingly. After receiving a service request from the vehicle-side controller, it sends static topology information to the vehicle-side controller. After receiving a decision assistance request, it sends operating status information at preset intervals, enabling the vehicle-side controller to generate candidate paths and determine target paths based on the static topology information and operating status information, and control the vehicle to perform parking actions based on the target path.

[0107] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0108] To facilitate understanding, the following will be combined with... Figure 1 The application scenarios applicable to the embodiments of this application will be described.

[0109] Figure 1 This is a schematic diagram illustrating an application scenario of the parking planning method provided in this application. Please refer to [link / reference]. Figure 1 The application scenario includes: vehicle-side controller 110 and field-side server 120.

[0110] The vehicle-side controller 110 is deployed inside the vehicle (as shown in the figure, a truck or passenger car) and is used to collect local perception data of the vehicle, process user interaction commands, and control the vehicle's driving and parking actions.

[0111] The parking lot server 120 is deployed in the parking lot management center or the cloud to store and manage the full data set of parking lot information (including static topology information and dynamic real-time information) and provide decision support to the vehicle controller 110.

[0112] In this embodiment, the vehicle-side controller 110 and the field server 120 can establish a communication connection through a wireless communication network. Specifically, the wireless communication network may include, but is not limited to, the 4th Generation Mobile Communication Technology (4G), the 5th Generation Mobile Communication Technology (5G), Vehicle-to-Everything (V2X) wireless communication technology, or Wireless Fidelity (Wi-Fi).

[0113] Through the aforementioned communication link, the vehicle-side controller 110 and the parking lot server 120 can work together to execute the parking planning method provided in this embodiment. Specifically, the parking lot server 120 is responsible for constructing the global situation and distributing the basic map and dynamic status information, while the vehicle-side controller 110 performs path planning and obstacle avoidance control based on the received information, thereby achieving efficient and safe automatic parking.

[0114] It should be noted that, Figure 1 The illustration uses only one vehicle and one server as an example. In actual applications, this scenario can include multiple vehicles interacting with the same site server 120 at the same time. The vehicle type is not limited to the truck shown in the illustration, but can also be other vehicles with autonomous driving or assisted driving functions such as passenger cars and logistics vehicles.

[0115] Figure 2 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 1 .like Figure 2 As shown, the method includes:

[0116] S201. Obtain the full data set of parking lot information.

[0117] The full data dataset includes static topology information and dynamic real-time information.

[0118] In this step, the full information dataset serves as the basic data set for supporting parking planning on the parking lot side. It includes at least static topological information representing the fixed structure of the parking lot and dynamic real-time information representing the current changes in the parking lot.

[0119] Static topology information is used to describe the spatial structural constraints within a parking lot that are relatively fixed and do not change with vehicle movement within a preset period of time. Specifically, it may include information such as the location of the parking lot entrance and exit, floor relationships, lane center lines, lane widths, lane driving directions, turning connections, ramp locations, parking space layouts, parking space numbers, road boundaries, pillars, walls, medians, height restriction components, toll gates, traffic signs, and restricted area boundaries.

[0120] Dynamic real-time information is used to describe the real-time changes in the parking lot's operation. Specifically, it can include the occupancy status of each parking space, vehicle location and movement trajectory, road section traffic status, temporary closure information, location of low obstacles, pedestrian activity areas, construction barriers, queue length, congestion level, and areas with localized obstructed views.

[0121] Based on the above analysis, it can be concluded that the entity that acquires the full data set can be a server on the parking information management side, an edge computing gateway, or a management controller deployed in the parking lot. This entity can establish communication connections with multiple source devices in the parking lot to form a unified collection of the static structure and dynamic status of the parking lot.

[0122] In one possible embodiment, static topology information can be imported into the system by surveying equipment, architectural design drawing parsing system, or parking lot operation and maintenance terminal before the parking lot is put into use, forming a basic topology database.

[0123] To address discrepancies between drawings and reality, inspection vehicles equipped with cameras, lidar, or ultrasonic ranging units can verify the boundaries of roads, parking spaces, and access nodes within the site. The verification results are then written into a static topology database after coordinate alignment.

[0124] Dynamic real-time information can be continuously reported by parking space detectors, video cameras, millimeter-wave radar, lidar, geomagnetic sensors, barrier gate controllers, elevator or ramp access recording devices, and event logs from parking management platforms.

[0125] In practice, the server on the parking lot side can first uniformly calibrate the timestamps of data from each collection source, and then map the heterogeneous data to the same spatial reference frame according to the parking lot's internal coordinate system. For similar status information from different devices, it can be fused according to device reliability, collection latency, and most recent update time to generate data records that can be directly used for subsequent status judgment. For example, the occupancy status of a parking space can be output from both a geomagnetic sensor and a video recognition result. When inconsistency is detected, a valid value can be selected based on the most recent sampling time and a preset confidence level, or the dual-source results can be retained for subsequent conflict resolution.

[0126] For example, the full data dataset is not generated once and for all, but is continuously updated during the operation of the parking lot. Static topology information is updated after structural adjustments, parking space rezoning, and access road modifications, while dynamic real-time information is written in a rolling manner at intervals of seconds or even shorter.

[0127] By incorporating the fixed structure and real-time changing status of parking lots into the same dataset, a complete data foundation can be provided for the accurate determination of subsequent operational status information, enabling vehicle-side parking planning to no longer rely solely on information within the visible range of local sensors.

[0128] S202. Determine the operating status information within the parking lot based on static topology information and dynamic real-time information.

[0129] In this step, the operational status information is a structured representation of the overall current operational status of the parking lot. It can be determined by both static topology information and dynamic real-time information, and serves as the basis for subsequent decision-making when sent to the vehicle-side controller.

[0130] In this step, static topology information is used to provide the basic spatial constraints and regional connectivity of the parking lot, while dynamic real-time information is used to reflect the occupancy, access, and change status of each area within the parking lot at the current moment. The combination of the two can form operational status information that can directly serve path generation.

[0131] Based on the above analysis, it can be seen that the operational status information is not a simple forwarding of the original dynamic data, but rather a status result obtained by the parking lot side based on the overall structural relationship of the parking lot, after locating, classifying, and associating real-time changes. The operational status information can include parking space availability status, lane segment traffic status, area congestion status, node passage priority status, temporary obstacle status, local risk area status, and recommended detour status, and can be organized according to lane segments, intersection nodes, parking units, floor areas, or target parking space sets.

[0132] In one possible embodiment, the parking lot can correlate static topology information and dynamic real-time information to generate operational status information characterizing the current operation of the parking lot. For continuously updated dynamic real-time information, fusion and status determination processing can be performed to improve the stability and accuracy of the operational status information.

[0133] For example, the running status information may also include the status generation time, status validity period, and status confidence level, so that the vehicle-side controller can decide whether to use the corresponding status for path recalculation based on the receiving time.

[0134] In another implementation, when the parking lot changes rapidly, the parking lot side can increase the frequency of state calculations and prioritize writing the segments with larger changes into the operational state information. By unifying the analysis of static topological constraints and dynamic real-time changes, this step enables the global state within the parking lot to be expressed in a way suitable for path planning. The vehicle end does not obtain fragmented perception results, but rather a computable state that has been associated with the parking lot structure, thereby making the generation of subsequent candidate paths more closely match the actual operating conditions within the parking lot.

[0135] S203. Receive the service request sent by the vehicle controller and send static topology information to the vehicle controller according to the service request.

[0136] In this step, the service request is a request message sent by the vehicle controller to the parking lot side in order to obtain parking lot structure information. As the execution subject on the vehicle side, the vehicle controller can establish a global understanding of the parking lot structure and generate subsequent feasible paths after receiving the static topology information returned by the parking lot side.

[0137] A service request can include at least the vehicle identifier, the current entrance or location, the target service type, the communication session identifier, and the request time. After receiving the service request, the parking lot identifies the parking task to which the corresponding vehicle belongs, extracts the static topology information related to the current task from the static topology database, and then sends it to the vehicle controller.

[0138] In this step, static topology information can be either global parking lot topology data or topology data determined based on the vehicle's current location, reachable area, or target business scope, while ensuring the integrity of route planning. This reduces the amount of data transmitted and shortens the vehicle-side mapping time.

[0139] In one possible embodiment, after a vehicle enters the parking lot entrance, approaches the barrier gate area, or enters the automatic parking waiting area, the vehicle-side controller can send a service request to the parking lot side via cellular communication, wireless local area network, dedicated short-range communication link, or the parking lot's internal local area network.

[0140] After receiving a service request, the parking lot can determine the range of static topology information to be sent based on the request. During transmission, the parking lot can encode the static topology information according to a predetermined data format before sending it to the vehicle controller. Upon receiving the information, the vehicle controller can write the static topology information into its local map cache and establish a mapping relationship corresponding to the vehicle's coordinate system, ensuring that subsequently received real-time operational status information can be accurately overlaid onto the same map frame.

[0141] For example, when receiving a service request for the first time, the parking lot can send complete static topology information for the current version. When the vehicle controller detects that the static map version has expired, the parking lot has undergone a structural update, or the vehicle has switched to a new reachable area, it can send updated static topology information again.

[0142] Based on the above analysis, this step provides the vehicle with fixed structure data of the parking lot before parking decision-making, so that the vehicle has a global spatial constraint basis when generating candidate paths, and no longer relies on the local structure cognition formed by on-site exploration by vehicle sensors.

[0143] S204. Receive the decision assistance request sent by the vehicle controller, and send the operation status information to the vehicle controller at a preset period according to the decision assistance request, so that the vehicle controller can generate candidate paths and determine target paths according to static topology information and operation status information, and control the vehicle to perform parking actions based on the target paths.

[0144] In this step, the decision support request is a request message issued by the vehicle-side controller after obtaining static topology information in order to continuously acquire the real-time operating status of the parking lot. The preset period controls the frequency of sending operating status information; this period can be a fixed time interval or adjusted according to the degree of change in the parking lot's status.

[0145] In this step, the operational status information serves as dynamic decision data continuously output from the parking lot's side to the vehicle-side controller. Upon receiving this operational status information, the vehicle-side controller integrates it with the received static topology information to generate several candidate paths. It then determines the target path from these candidate paths and controls the vehicle to proceed towards and park in the target parking space according to the target path. The candidate paths are a set of multiple alternative paths that satisfy both the parking lot's static structural constraints and the current dynamic access constraints. The target path is the final path selected from this set, considering the current status, parking space accessibility, and vehicle control constraints.

[0146] In one possible embodiment, after completing the static topology information parsing, the vehicle-side controller can send a decision assistance request to the parking lot side. The decision assistance request may include the vehicle's current location, current attitude, target parking space intention, reception cycle requirement, remaining computing power identifier, and task priority.

[0147] After receiving the decision assistance request, the parking lot can create a status push session corresponding to the vehicle and send the operational status information according to a preset period. The preset period can be set to a time interval between 100 milliseconds and 2 seconds. A shorter period can be used in areas with high vehicle density and frequent status changes within the parking lot, while a longer period can be used in areas far from congested areas and with stable status.

[0148] If an adaptive periodic mechanism is adopted, the parking lot can adjust the transmission frequency based on the number of parking space status changes, lane congestion events, and average vehicle speed fluctuations per unit time. For example, when a certain area experiences multiple occupancy status changes and vehicle queue growth within several consecutive sampling periods, the transmission period for operational status information can be shortened to half of the original period. When the status remains stable for several consecutive periods, the transmission period can be restored to the preset basic period.

[0149] The transmitted operational status information may include a list of currently available parking spaces, the passage cost for each section, the identifier of congested sections, the congestion level, temporary restricted access points, and the corresponding status timestamp.

[0150] After receiving the data, the vehicle-side controller can map each status record to the corresponding node or edge in the local static topology graph and update the cost parameters of the path search accordingly.

[0151] Specifically, the vehicle-side controller can set the passage cost of blocked edges to unreachable, increase the cost of congested edges according to the congestion level, and set the arrival reward of the node corresponding to the available parking space as a valid candidate target. This generates multiple candidate paths from the current location to the entrance point of a candidate parking space on the topology graph. Then, combining the vehicle's minimum turning radius, reversing limit, path length, estimated travel time, and state freshness, the target path is determined from the candidate paths. During vehicle execution, the vehicle-side controller can output steering, braking, driving, and gear shifting control commands according to the target path, while continuing to receive periodic operational status information from the parking lot. When newly received operational status information indicates that the section ahead of the target path is blocked, the target parking space is occupied, or a new risk area exists, the vehicle-side controller can regenerate candidate paths and update the target path until the vehicle reaches an available parking space and completes the parking maneuver.

[0152] Based on the above analysis, this step continuously introduces the global dynamic state of the parking lot into the vehicle-side decision loop, so that the vehicle-side path planning is not only subject to static topology constraints, but also corrected in real time by the on-site operating state. This enables the path planning to maintain consistency with the on-site state in parking lot environments with complex structures, dense parking spaces, and continuously changing traffic conditions, reducing path deviations and parking failures caused by insufficient local perception on the vehicle side.

[0153] This application provides a parking planning method applicable to a parking lot server, comprising: acquiring a full data set of parking lot information, including static topology information and dynamic real-time information; determining the operational status information within the parking lot based on the static topology information and dynamic real-time information; receiving a service request sent by a vehicle-side controller, and sending static topology information to the vehicle-side controller based on the service request; receiving a decision assistance request sent by the vehicle-side controller, and sending operational status information to the vehicle-side controller at a preset period based on the decision assistance request, so that the vehicle-side controller can generate candidate paths and determine target paths based on the static topology information and operational status information, and control the vehicle to perform parking actions based on the target paths. In this application embodiment, the parking lot side first aggregates fixed structure information and real-time change information of the parking lot, and then merges the two to form an operational status expression that can be used for path decision-making, and provides static topology information and periodically updated operational status information to the vehicle-side controller under the triggering of service requests and decision assistance requests, respectively. The vehicle-side controller can establish a global structure understanding and continuously correct path decisions accordingly. This implementation method enables parking planning to rely on information that covers both the static spatial relationships of the parking lot and the dynamic states such as parking space occupancy, traffic changes, and temporary obstacles. Therefore, in complex parking lot environments, it can support the vehicle to form candidate paths and target paths that match the on-site conditions.

[0154] Figure 3 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 2 .like Figure 3 As shown, S202, based on static topology information and dynamic real-time information, determines the operating status information within the parking lot, including:

[0155] S301. Construct a topological map of the parking lot based on static topological information.

[0156] S302. Map dynamic real-time information onto the topology map, and generate a real-time global situation map of the field end through spatiotemporal alignment, which serves as the operational status information.

[0157] In practical implementation, static topology information can first undergo coordinate unification and semantic fusion to generate a topology map data structure containing road nodes, connected edges, and parking space units. Then, dynamic real-time information is projected onto the corresponding road nodes, parking space units, or service areas according to their spatial coordinates. Furthermore, dynamic information from different sources is synchronously corrected based on timestamps, ensuring that the status of vehicles, pedestrians, and service resources at the same moment corresponds to the same spatiotemporal location on the topology map, thereby forming a real-time global situational awareness map. After this real-time global situational awareness map is output as operational status information, it can be directly used by the vehicle-side controller for path candidate generation and target path determination.

[0158] In this embodiment, the topology map decouples the static structure from the dynamic state, while the real-time field-side global situation map embeds local dynamic changes into the global structure, enabling the vehicle to obtain the complete field state based on a unified coordinate system. Because the dynamic information is output after spatiotemporal alignment, the operating state information obtained by the vehicle is consistent with the actual field location and time, thereby improving the completeness and usability of the state expression and providing a more stable input basis for subsequent parking path planning.

[0159] S203. Receive a service request sent by the vehicle controller, and send static topology information to the vehicle controller according to the service request, including:

[0160] S303, parse the service request to obtain vehicle size parameters.

[0161] S304. Filter out passable areas and available parking spaces that meet the vehicle size parameters from the static topology information;

[0162] S305. Send the filtered static topology information to the vehicle controller.

[0163] In actual processing, after the vehicle-side controller sends a service request to the parking lot information management side, the parking lot information management side can parse the service request message, extract the vehicle model, external dimension identifier or directly carried vehicle length, width and height data, and generate vehicle size parameters accordingly.

[0164] When the service request only contains the vehicle model identifier, the corresponding standard size parameters can be queried through the vehicle model mapping table. When the service request contains the measured size, the measured value can be used directly as the filtering criterion.

[0165] Subsequently, the parking information management side can perform constraint matching on road connectivity segments, turning nodes, entrance / exit passages, and parking space boundaries in the static topology information based on vehicle size parameters. Areas with insufficient width, insufficient turning space, or parking boundaries that do not meet requirements are eliminated, retaining passable areas that meet vehicle traffic conditions and available parking space information that meets parking conditions. The filtering results can be organized into a static topology subset containing area identifiers, spatial boundaries, connectivity relationships, and parking space identifiers, and sent to the vehicle-side controller via a communication interface for candidate path generation and target parking path selection.

[0166] In this process, static topology information can be stored as parking lot topology map data. Each node in the map data represents a channel connection point, parking space entrance point, or corner point; each edge represents a road segment or guide segment; and parking space information records the parking space number, geometric dimensions, and orientation. During filtering, the effective net width, minimum turning space, and parking space envelope of each road segment can be calculated based on vehicle size parameters. The calculation results are then compared with a preset passage threshold to determine whether to include the vehicle in the transmission range. This method allows the static topology information received by the vehicle controller to be adapted to the current vehicle size. Based on this, the vehicle controller can generate candidate paths only within the reachable area and perform parking decisions only for available parking spaces. Therefore, the information sent to the vehicle controller can be targeted, reducing the amount of invalid topology content transmitted and enabling the vehicle controller to obtain passage and parking information matched to the vehicle's own size.

[0167] Figure 4 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 3 .like Figure 4 As shown, the method includes:

[0168] S401: In response to a parking request initiated by a user, a service request containing vehicle size parameters is sent to the parking lot.

[0169] In this embodiment, the parking request is used to trigger the parking planning process. Specifically, it can be triggered by the user selecting the target parking lot and clicking the parking entrance on the vehicle interface, initiating a valet parking command on the mobile terminal, or by the vehicle arriving at the parking lot entrance area based on human-computer interaction confirmation information.

[0170] Vehicle size parameters are used to characterize the vehicle's external dimensions and turning boundaries. Specifically, they may include at least one of the following parameters: vehicle length, vehicle width, vehicle height, wheelbase, front and rear overhang lengths, and minimum turning radius. Among these, vehicle length, vehicle width, and wheelbase can be used as basic parameters in subsequent traffic adaptation calculations.

[0171] Service requests are business request messages sent from the vehicle to the parking lot. The parking lot is an information management and decision support node on the parking lot side, which can be deployed as a local server of the parking lot, an edge computing gateway, or a back-end control platform connected to the parking lot's sensing facilities.

[0172] In practice, after receiving a parking request initiated by the user, the vehicle-side controller can call the vehicle parameter management module to obtain the vehicle size parameters, and encapsulate the relevant vehicle size parameter information into a service request and send it to the field terminal.

[0173] The current pose information can be jointly determined by the onboard positioning unit to indicate the vehicle's current location. Service requests can be sent to the field station via the onboard communication unit. Upon receiving the service request, the field station can identify the vehicle's passage space requirements based on vehicle size parameters. In some optional implementations, the service request may also carry auxiliary parameters related to information interaction.

[0174] Based on the above analysis, it can be seen that sending a service request containing vehicle size parameters at the beginning of the parking process can make the static topology information returned by the parking lot consistent with the spatial constraints of the current vehicle. Subsequent path search is no longer based on a general vehicle model, but is based on the actual vehicle envelope range, thus making the filtering results of passable paths directly executable.

[0175] S402, Receive static topology information sent by the field end in response to the service request.

[0176] In this embodiment, static topology information is used to describe the relatively stable spatial structure relationships within the parking lot, and may include several items such as the parking lot lane network, intersection nodes, traffic boundaries, ramp locations, height restriction facility locations, restricted areas, and floor connection relationships. The lane network in the static topology information can be expressed in the form of a directed graph, where nodes represent turning decision points, intersection points, or connection points, and edges represent lane segments available for vehicle travel. Each edge may be accompanied by length, width, traffic direction, curvature constraints, and slope attributes.

[0177] In practice, after receiving a service request, the parking lot operator can retrieve basic topology data from the static map data and perform adaptation processing based on the vehicle size parameters carried in the service request. The adaptation processing includes marking passage areas that do not match the vehicle size parameters as impassable or removing them from the topology.

[0178] After adaptation, the parking lot controller can send static topology information adapted to the current vehicle to the vehicle controller. Upon receiving the static topology information, the vehicle controller can reconstruct the parking lot topology map structure and boundary constraint information, and store it locally for subsequent planning. In some optional implementations, the static topology information may also include parking lot rule information, which the vehicle controller can incorporate as a constraint condition into the search during the subsequent path generation phase.

[0179] Based on the above analysis, after receiving and parsing the static topology information filtered by vehicle size parameters, the vehicle-side controller obtains a spatial base map that is consistent with the fixed structure of the parking lot and adapted to the vehicle. Subsequent path planning is only carried out within the feasible area, which enables the candidate path generation stage to directly avoid physically impassable lane segments.

[0180] S403. Send a decision support request to the field terminal and receive the operation status information sent by the field terminal in response to the decision support request at a preset period.

[0181] The operational status information is determined by the site management based on the full data set of parking lot information, which includes static topology information and dynamic real-time information.

[0182] In this embodiment, the decision support request is used to establish a continuous state coordination channel between the vehicle and the parking lot. Operational status information is used to characterize the parking lot's current state and the state results related to traffic and parking over continuous periods. The full data set consists of static topology information and dynamic real-time information, where the dynamic real-time information characterizes the parking lot's real-time changing state and may include traffic density, queue length, temporary obstacles, construction closures, waterlogged areas, abnormally parked vehicle locations, high-frequency pedestrian crossing areas, and localized congestion detected by cameras or roadside sensing devices.

[0183] Instead of directly forwarding all the raw dynamic data to the vehicle controller, the field terminal performs fusion calculations based on static topology information, and outputs operational status information that can be directly used for path planning, such as edge weight update results, node conflict risk levels, zone congestion levels, and a list of temporarily unreachable areas.

[0184] In practice, after receiving the static topology information, the vehicle-side controller can generate a decision support request and send it to the field controller. This decision support request may include information such as the vehicle's current location, the current planning stage identifier, and the expected update cycle.

[0185] After receiving the decision assistance request, the parking lot controller can initiate a status push task for the vehicle session. The preset period can be set according to the dynamic change frequency of the parking lot, or adaptively adjusted according to vehicle speed, congestion level within the parking lot, and obstacle change frequency. When constructing operational status information, the parking lot controller can first read various dynamic real-time information, then perform spatial registration with the static topology map, mapping dynamic changes to corresponding lane edges or nodes. Subsequently, the parking lot controller can calculate the passage cost of key lane segments, node conflict risk, and regional accessibility status based on the fusion results, and send the operational status information to the vehicle controller. After receiving the operational status information each time, the vehicle controller can update the status attributes of the corresponding edges and nodes in the local map, triggering replanning when necessary.

[0186] Based on the above analysis, it can be seen that by establishing continuous information interaction through decision support requests, and forming operational status information from the full information dataset composed of static topology information and dynamic real-time information at the site, the vehicle controller obtains the status result that has completed the global fusion processing within the site, rather than local original perception fragments. Therefore, it is possible to promptly grasp the actual impact of traffic flow changes and temporary obstacle changes on path accessibility in complex parking lots, thereby solving the problem of incomplete information caused by relying solely on the limited perception of the vehicle.

[0187] S404. Generate multiple candidate paths based on static topology information and operational status information.

[0188] In this embodiment of the application, the candidate path is a set of multiple alternative driving routes generated based on the vehicle's current location, static topology information and operating status information. Each candidate path can be composed of a series of continuous lane segments and turning nodes.

[0189] Static topology information can provide the fixed spatial structure and rule constraints of the parking lot, while operational status information can provide the dynamic feasibility and passage cost of each path segment at the current moment. The vehicle-side controller can generate candidate paths under the combined constraints of static topology information and operational status information.

[0190] The candidate path is not simply a list of multiple shortest distance routes, but rather a set of executable paths that simultaneously satisfy vehicle size constraints, kinematic constraints, traffic rule constraints, and real-time state constraints.

[0191] In practice, the vehicle controller can first construct a directed topology graph with attributes based on static topology information, mapping the vehicle's current position to the starting node or starting edge in the graph. Subsequently, the vehicle controller can write the operating status information into the edge weights and node constraints of the topology graph. The edge weights can include distance cost, estimated travel time cost, and dynamic risk cost, while the node constraints include at least whether a turn-in is currently allowed, whether there is a temporary conflict, and whether waiting is required.

[0192] Path search can employ the K-shortest path algorithm, an extended A* search algorithm, or a constraint graph-based multi-path search algorithm. To ensure the generated path aligns with the vehicle's actual controllable trajectory, the vehicle-side controller, after completing the graph search, can perform geometric unfolding and trajectory smoothing on each path, and verify whether the trajectory satisfies the vehicle's minimum turning radius and collision-free envelope constraints at each turning point and ramp segment. In one possible embodiment, the vehicle-side controller can first perform an initial screening of the search range before generating candidate paths to control the computational load.

[0193] Based on the above analysis, it can be seen that multiple candidate paths are generated under the combined effect of static topology information and operational status information. This provides the vehicle with a multi-planning foundation for the current environment. The path set composed of multiple candidate paths can simultaneously reflect both the fixed structure of the parking lot and real-time operational status changes. Even if some paths become invalid due to status changes, there are still alternative paths available to continue the parking task.

[0194] S405. Conduct a comprehensive analysis of multiple candidate paths to determine the target path.

[0195] In this embodiment of the application, comprehensive analysis is a process of uniformly evaluating candidate paths under multi-dimensional constraints and selecting the final execution path. The target path is the candidate path whose evaluation results meet the execution conditions and whose ranking is optimal.

[0196] Comprehensive analysis can be conducted focusing on traffic efficiency, traffic safety, and control feasibility. Traffic efficiency can be characterized by total path length, estimated travel time, intersection waiting time, and congestion clearance time. Traffic safety can be characterized by obstacle proximity, number of conflict nodes, blind spot clearance length, and the proportion of temporary risk areas. Control feasibility can be characterized by curvature change rate, number of reversing maneuvers, and narrow passage length.

[0197] In practice, the vehicle-side controller can extract the corresponding feature parameters for each candidate path and calculate the path score according to a unified evaluation model.

[0198] For example, the vehicle-side controller can construct a comprehensive cost function F = a × T + b × R + c × C, where T represents the estimated travel time cost, R represents the dynamic risk cost, C represents the control complexity cost, and a, b, and c are the corresponding weight coefficients, each of which can be preset by the configuration file.

[0199] The congestion level, obstacle changes, and conflict node status reflected in the operational status information directly affect the values ​​of T and R, while the turning radius limit, lane width, and road geometry in the static topology information directly affect the value of C. After completing the scoring, the vehicle-side controller can first eliminate candidate paths that do not meet the hard constraints, such as paths with closed sections, vehicle size exceeding limits, or trajectory collision risks. Then, it can select the candidate path with the lowest overall cost or the highest overall score from the remaining paths as the target path.

[0200] When the evaluation results of multiple candidate paths are close, the vehicle-mounted controller can further determine the target path based on the state stability index. The stability index is used to characterize the degree of fluctuation of the relevant area of ​​the path over multiple consecutive state cycles. The path with the smaller fluctuation can be selected as the target path. If the field pushes new operating status information after the target path is selected and indicates that the state of the key edges in the path has changed, the vehicle-mounted controller can perform a quick review of the current target path. If the review fails, it can fall back to the candidate path set to reselect the target path or regenerate candidate paths.

[0201] Based on the above analysis, it can be seen that by comprehensively analyzing multiple candidate paths and determining the target path, the final execution route is not simply the shortest route, but a route that matches the current dynamic state of the parking lot and the constraints of the vehicle itself, thereby enabling the subsequent control process to have higher execution consistency.

[0202] S406. Based on the target path, control the vehicle to perform parking actions.

[0203] In this embodiment, parking is a control process in which the vehicle travels from its current location to a target location within the parking lot according to a target path. This includes at least path tracking, node steering control, speed control, oncoming traffic or waiting control, and terminal parking control. After entering the control phase, the target path can be decomposed into several control segments. Each control segment includes a desired trajectory point, a desired vehicle speed, steering curvature, and segment termination conditions. The vehicle-side controller can generate lateral and longitudinal control commands based on the target path and issue them to the steering actuator, drive actuator, and braking actuator.

[0204] In practice, the vehicle-side controller first discretizes the target path in time and space, generating a sequence of trajectory points sampled by time or distance. Each trajectory point contains position coordinates, heading angle, target speed, and curvature value. Subsequently, it can calculate steering angle commands based on the lateral and heading deviations between the current vehicle state and the trajectory points, and calculate drive torque or braking force commands based on the target speed and the forward conditions.

[0205] As the vehicle moves along the target path, the vehicle-mounted controller can continuously receive the operating status information periodically sent by the field terminal and perform online verification of the target path.

[0206] When an impassable segment of the target path is detected ahead, the vehicle-side controller can pause execution of subsequent segments and enter a replanning process based on the latest static topology and operational status information. Upon reaching the end of the path, the control strategy can switch to terminal parking control, where the vehicle sequentially performs deceleration, corrects vehicle attitude, switches steering, and finally brakes to a stop until parking is completed.

[0207] In one possible embodiment, the vehicle-side controller can set a safety monitoring threshold during the parking maneuver. When any parameter such as vehicle speed, lateral deviation, remaining forward distance, or obstacle spacing exceeds the threshold, a braking command can be immediately output and the field-side operating status information can be reconfirmed.

[0208] Based on the above analysis, it can be seen that by controlling the vehicle to perform parking actions based on the target path and continuously verifying the operation status information of the parking lot during the execution process, the vehicle can complete the driving and parking according to the selected path even when the dynamic environment of the parking lot is constantly changing. The path planning result and the vehicle control result are consistent, thus completing autonomous parking in the parking lot.

[0209] This application provides a parking planning method applicable to a vehicle-side controller. The method includes: responding to a user-initiated parking request by sending a service request containing vehicle size parameters to a parking lot control unit; receiving static topology information from the parking lot control unit in response to the service request; sending a decision assistance request to the parking lot control unit; and receiving operational status information from the parking lot control unit at preset intervals in response to the decision assistance request. The operational status information is determined by the parking lot control unit based on a full dataset of parking lot information, which includes static topology information and dynamic real-time information. Based on the static topology information and operational status information, multiple candidate paths are generated; the multiple candidate paths are comprehensively analyzed to determine a target path; and based on the target path, the vehicle is controlled to perform a parking action. In this application embodiment, the parking lot control unit is responsible for generating static topology information adapted to the current vehicle and continuously updating operational status information based on global parking lot data. The vehicle-side controller can complete candidate path generation, target path determination, and vehicle control execution based on the received information. This ensures that path planning is simultaneously constrained by the fixed structure and real-time operational status of the parking lot, enabling parking planning and execution that matches vehicle size to be completed in complex, densely packed, and dynamically changing parking lot environments.

[0210] Figure 5 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 4 .like Figure 5 As shown, S406, based on the target path, controls the vehicle to perform a parking action, including:

[0211] S501. Acquire local perception data collected by vehicle-side sensors.

[0212] S502. The local sensing data and the operating status information are fused to generate fused environment information.

[0213] S503. Based on the integrated environmental information and target path, control the vehicle to perform parking actions.

[0214] Specifically, after acquiring local perception data, the vehicle-side controller can perform consistency verification between the local perception data and operational status information based on spatial location matching relationships. It can also comprehensively analyze the occupancy, accessibility, and obstacle status of the same target area to generate corresponding fused environmental information. This fused environmental information can take the form of a grid occupancy map, an object list, or semantic annotation results, facilitating subsequent path tracking and trajectory control.

[0215] When controlling a vehicle to perform parking maneuvers based on fused environmental information and the target path, the vehicle-mounted controller can match the path points, heading angles, and speed constraints in the target path with the fused environmental information to obtain the steering control, braking control, and drive control quantities at the current moment. Based on this, the controller can control the vehicle to complete forward, reverse, steering, and parking maneuvers. If the fused environmental information indicates the presence of temporary obstacles or changes in parking space boundaries near the target path, the vehicle-mounted controller can adjust the trajectory tracking parameters and update the control commands according to the fusion results, ensuring the vehicle continuously completes parking along a path consistent with the actual conditions.

[0216] By fusing local sensing data with operational status information, the vehicle-side controller can simultaneously utilize real-time sensing results from near-field locations and dynamic status results provided by the parking lot to participate in control decisions. This ensures that parking actions are consistent with the actual traffic conditions in the parking lot, improving the accuracy of path tracking and the stability of action execution, and reducing control deviations caused by local occlusion or delayed status updates.

[0217] Specifically, in the process of controlling the vehicle to perform a parking maneuver, the vehicle-mounted controller collects local perception data through onboard sensors (such as LiDAR and cameras) and aligns this data with the operational status information sent by the site control center in both time and space. Specifically, the vehicle-mounted controller maps the local perception data to a global topology map through coordinate system transformation and resolves conflicts by combining this data with information such as the location of dynamic obstacles and the occupancy status of parking spaces from the operational status information. For example, when there is an inconsistency between the local perception data and the operational status information in a certain area (e.g., the site control center reports that the parking space is vacant but the vehicle-mounted controller detects a low obstacle), the vehicle-mounted controller prioritizes the local perception data and reports the abnormal status to the site control center to trigger a data update.

[0218] Based on the aforementioned embodiments, further, S503, controlling the vehicle to perform a parking action according to the fused environmental information and the target path, also includes:

[0219] S5031. Based on the integrated environmental information, perform local dynamic obstacle avoidance planning on the target path to generate a target path containing local obstacle avoidance trajectories.

[0220] S5032. Control the vehicle to perform a parking maneuver based on the target path containing a partial obstacle avoidance trajectory.

[0221] In its implementation, after receiving the target path, the vehicle-side controller can establish a local obstacle model based on fused environmental information and perform collision checks on the target path segment from the vehicle's current position to the parking endpoint. When an obstacle intrusion, boundary contraction, or passage conflict is detected in a local area, path interpolation and trajectory smoothing can be performed on that local area to generate a new local obstacle avoidance trajectory. This local obstacle avoidance trajectory can be expressed using spline curves, circular transition segments, or piecewise polygonal lines, and smoothly connected to the preceding and following segments of the original target path, thus obtaining the target path containing the local obstacle avoidance trajectory.

[0222] Subsequently, the vehicle-mounted controller can output steering angle, drive torque, braking force and vehicle speed control commands according to the target path containing the local obstacle avoidance trajectory, so that the vehicle can complete the detour when it drives to the local conflict area, and return to the original parking orientation after passing through the area to continue the parking action.

[0223] Specifically, in the local dynamic obstacle avoidance planning step, the vehicle-mounted controller constructs a local obstacle model based on fused environmental information and can generate an obstacle avoidance trajectory using a spline curve fitting algorithm. In practice, when the vehicle-mounted controller detects a temporary obstacle (such as a construction site barrier) ahead, it first calculates the minimum safe distance between the obstacle and the target path, and then generates a local obstacle avoidance trajectory using circular transition segments or segmented polylines. The generated obstacle avoidance trajectory must satisfy vehicle kinematic constraints (such as minimum turning radius and maximum acceleration) and smoothly connect with the original target path to ensure that the vehicle can return to its original path and continue parking after passing through the conflict area.

[0224] During operation, local dynamic obstacle avoidance planning reconstructs the target path based on integrated environmental information, preventing the target path from continuing to follow the original path after the appearance of dynamic obstacles. The target path containing the local obstacle avoidance trajectory serves as the direct input for vehicle motion control, enabling the vehicle to complete local obstacle avoidance without altering the overall parking intention. In this way, the vehicle can promptly correct the local path based on real-time integrated information in complex parking lots, maintaining a continuous and executable parking trajectory, thereby improving the stability and path adaptability of parking control.

[0225] Figure 6 A flowchart illustrating a parking planning method provided in this application embodiment. Figure 5 .like Figure 6 As shown in S405, a comprehensive analysis of multiple candidate paths is performed to determine the target path, including:

[0226] S601. Obtain user historical behavior data and site service resource information.

[0227] S602. Based on user historical behavior data and site service resource information, score multiple candidate paths.

[0228] S603. The candidate path with the highest score is determined as the target path.

[0229] User historical behavior data reflects users' past travel and usage habits, while on-site service resource information characterizes the occupancy status, queuing status, or service capacity of available service resources within the site. Both can jointly constitute the input basis for candidate route scoring. User historical behavior data can be generated from vehicle account records, historical parking records, historical arrival times, charging records, or car wash records. On-site service resource information can be distributed in real time by the on-site management system and can correspond to charging pile occupancy rates, car wash queue times, maintenance bay vacancy status, or other service resource statuses.

[0230] After acquiring the aforementioned user historical behavior data and site service resource information, the path features corresponding to each candidate path can be correlated with the user historical behavior data and site service resource information to form a score result for the candidate path. The path features of the candidate path may include traffic efficiency, estimated travel time, detour distance, matching degree of reaching service resources, and waiting time. Weighted summation, rule mapping, or a scoring model can be used to quantify each feature and output the corresponding comprehensive score. The scoring model can be deployed in the vehicle-side controller or site-side computing unit. When using preset weights, the weight parameters can be configured based on historical parking data, service resource usage frequency, or user preference tags. In practical applications, other models can also be selected for the scoring model; this embodiment does not specifically limit this.

[0231] After obtaining the combined scores of multiple candidate paths, they can be compared according to their scores, and the candidate path with the highest score can be determined as the target path. If there are candidate paths with the same score, a secondary determination can be made by combining the estimated arrival time of the candidate path, the idle window of the target service resource, or the path length, so as to output a unique target path. This target path can then be used for parking control, so that the vehicle performs parking actions along a path that matches the user's historical behavior data and the site service resource information.

[0232] Specifically, in the step of determining the target route, the vehicle-side controller comprehensively evaluates candidate routes using a scoring model. The input parameters of the scoring model include: user historical behavior data (such as preference for straight routes and avoidance of high-intensity areas) and on-site service resource information (such as the availability of charging stations and car wash queue times). For example, if user historical data indicates a preference for fast charging, the scoring model will prioritize routes closer to available charging stations and apply a penalty coefficient to routes passing through highly congested areas. The output of the scoring model is the comprehensive score of each candidate route, and the candidate route with the highest score can be determined as the target route.

[0233] By incorporating user historical behavior data and site service resource information into the candidate path scoring process, the determination of the target path is no longer constrained solely by the connectivity of parking lot roads. Instead, it simultaneously reflects user preferences and site resource status, thereby ensuring that the path selection results are consistent with actual service needs and improving the adaptability and execution accuracy of the target path.

[0234] Based on the foregoing embodiments, the method further includes:

[0235] S604. Monitor the changes in the status of service resources at the site while the vehicle is traveling along the target path.

[0236] S605. When the changing state satisfies the requirement that the idle resources at the field end match the current service demand list predicted based on the user's historical service list, service recommendation information is generated.

[0237] S606: Display service recommendation information to users through the in-vehicle interactive terminal.

[0238] Among them, the site service resource information is used to characterize the real-time status of the additional service resources that can be provided to user vehicles in the parking lot. The additional service resources may include charging piles, car wash bays, vehicle inflation equipment or other site service units open to parking users.

[0239] The in-vehicle interactive terminal is used to present service recommendation information to users and receive user confirmation. Specifically, it can consist of a vehicle screen, a voice output unit, or a pop-up display unit. In practical applications, this component can also take other forms, and this application embodiment does not limit this. The service recommendation information is used to prompt users with recommended content of available services, which may include information such as service type, resource location, current availability, queuing status, and reservation entry point.

[0240] In this embodiment, while the vehicle is traveling along the target path, the vehicle-mounted controller can continuously receive service resource status data uploaded or broadcast by the site, and compare the occupancy status, queuing time, available availability, or accessibility information of the same service resource at consecutive sampling times, thereby monitoring the changing status of the site's service resource information. The changing status can be characterized by the magnitude of the change, the number of changes, or the duration. When a change in the status of a service resource is detected to reach a preset threshold, or when the change continues for a preset duration, the vehicle-mounted controller can generate corresponding service recommendation information, associate this recommendation information with the current vehicle location, the target path stage, and the user's historical preferences, and send it to the in-vehicle interactive terminal for display. After the user confirms on the in-vehicle interactive terminal, the vehicle-mounted controller can also generate a service reservation request and send it to the site to complete the subsequent reservation interaction.

[0241] Specifically, in the step of generating service recommendation information, the vehicle-side controller can retrieve the user's historical service list from storage and determine whether the available resources at the charging station match the currently needed service resources predicted based on the user's historical service list by monitoring changes in the charging station's service resource information. Matching methods may include: the service resource idle window duration exceeding a user's historical usage frequency threshold (e.g., if a user frequently uses a charging station between 18:00 and 19:00, a recommendation can be triggered when an idle charging station is detected during that time period); or the service resource change exceeding a preset proportion (e.g., the charging station occupancy rate drops from 80% to 50%). When either condition is met, the vehicle-side controller can generate service recommendation information including service type, resource location, and reservation entry point, and display it to the user through the in-vehicle interactive terminal.

[0242] In this way, as the vehicle travels along the target path, it can simultaneously obtain the dynamic changes of the service resources at the site, and promptly present the available service information to the user when the idle resources at the site match the service content predicted based on the user's historical service list. This ensures that the service recommendations are consistent with the vehicle's driving status and the status of the site resources, thereby improving the timeliness, relevance, and scenario relevance of the recommended content.

[0243] Based on the foregoing embodiments, further, S606, after displaying service recommendation information to the user through the in-vehicle interactive terminal, also includes:

[0244] S607. In response to the user's confirmation of the service recommendation information, generate a service reservation request.

[0245] S608. Send the service reservation request to the site.

[0246] In actual operation, after displaying service recommendation information through the in-vehicle interactive terminal, user input can be continuously monitored. When a confirmation operation is detected, the service type, reservation time parameters, and associated identifiers in the recommendation information can be encapsulated to form a structured service reservation request, which can then be sent to the parking lot control system via the in-vehicle communication module. The in-vehicle communication module can use a cellular communication interface, a vehicle-to-everything (V2X) communication interface, or other wireless communication interfaces to ensure stable transmission of the service reservation request to the parking lot control system. After receiving the service reservation request, the parking lot control system can parse the service identifier in the request and complete the reservation process based on currently available service resources, thereby providing a data foundation for subsequent service connections after vehicles enter the parking lot.

[0247] Through the above methods, after the vehicle side completes the service recommendation display, it can directly convert the user's confirmation intention into a service reservation request and send it to the site. This enables the site to obtain the reservation request in a timely manner and execute the corresponding processing, thereby forming a coherent data loop between the recommendation information and the reservation result. This improves the timeliness and accuracy of the reservation information transmission and enables the site's service resources to be synchronously managed based on the user's confirmation result.

[0248] This application embodiment can divide the parking planning device or main control device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional module. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0249] Figure 7 A schematic diagram of the structure of a parking planning device provided in this application embodiment. Figure 1 .like Figure 7 As shown, the device includes: a first acquisition module 710, a determination module 720, a first transmission module 730, and a second transmission module 740.

[0250] The first acquisition module 710 is used to acquire the full information dataset of the parking lot, which includes static topology information and dynamic real-time information.

[0251] The determination module 720 is used to determine the operating status information within the parking lot based on static topology information and dynamic real-time information.

[0252] The first sending module 730 is used to receive service requests sent by the vehicle controller and send static topology information to the vehicle controller according to the service requests.

[0253] The second sending module 740 is used to receive decision assistance requests sent by the vehicle controller, and send operation status information to the vehicle controller at a preset period according to the decision assistance requests, so that the vehicle controller can generate candidate paths and determine target paths based on static topology information and operation status information, and control the vehicle to perform parking actions based on the target paths.

[0254] In one possible implementation, the determining module 720 is specifically used for:

[0255] Construct a topological map of the parking lot based on static topological information.

[0256] Dynamic real-time information is mapped onto the topology map, and a real-time global situation map of the field is generated through spatiotemporal alignment, which serves as operational status information.

[0257] In one possible implementation, the first transmitting module 730 is specifically used for:

[0258] Parse the service request to obtain the vehicle size parameters.

[0259] The passable areas and available parking spaces that meet the vehicle size parameters are filtered from the static topology information.

[0260] The filtered static topology information is sent to the vehicle-side controller.

[0261] Figure 8 A schematic diagram of the structure of a parking planning device provided in this application embodiment. Figure 2 .like Figure 8 As shown, the device includes: a third transmitting module 810, a first receiving module 820, a second receiving module 830, a generating module 840, an analysis module 850, and a control module 860.

[0262] The third sending module 810 is used to send a service request containing vehicle size parameters to the parking lot in response to a parking request initiated by the user.

[0263] The first receiving module 820 is used to receive static topology information sent by the field end in response to a service request.

[0264] The second receiving module 830 is used to send a decision assistance request to the parking lot and receive the operation status information sent by the parking lot in response to the decision assistance request at a preset period. The operation status information is determined by the parking lot based on the full information dataset of the parking lot. The full information dataset includes static topology information and dynamic real-time information.

[0265] The generation module 840 is used to generate multiple candidate paths based on static topology information and running status information.

[0266] Analysis module 850 is used to perform comprehensive analysis on multiple candidate paths to determine the target path.

[0267] The control module 860 is used to control the vehicle to perform parking actions based on the target path.

[0268] In one possible implementation, the control module 860 is specifically used for:

[0269] Acquire local perception data collected by vehicle-side sensors.

[0270] Local sensing data is fused with operational status information to generate fused environment information.

[0271] Based on the integrated environmental information and target path, the system controls the vehicle to perform parking actions.

[0272] In one possible implementation, the control module 860 is further configured to:

[0273] Based on the integrated environmental information, local dynamic obstacle avoidance planning is performed on the target path to generate a target path that includes local obstacle avoidance trajectories.

[0274] Based on the target path that includes a partial obstacle avoidance trajectory, control the vehicle to perform a parking maneuver.

[0275] In one possible implementation, the analysis module 850 is specifically used for:

[0276] Obtain user historical behavior data and site service resource information.

[0277] Based on user historical behavior data and on-site service resource information, multiple candidate paths are scored.

[0278] The candidate path with the highest score is selected as the target path.

[0279] In one possible implementation, the control module 860 is further configured to:

[0280] While the vehicle is traveling along the target route, monitor the changes in the status of the site service resources.

[0281] When the changing state matches the available resources at the site with the service content predicted based on the user's historical service list, service recommendation information is generated.

[0282] Service recommendations are displayed to users through the in-vehicle interactive terminal.

[0283] In one possible implementation, the control module 860 is further configured to:

[0284] In response to the user's confirmation of the service recommendation information, a service reservation request is generated.

[0285] Send the service reservation request to the site.

[0286] The parking planning device provided in this embodiment can execute a parking planning method of the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0287] In a specific implementation of the aforementioned parking planning device, each module can be implemented as a processor. The processor can execute computer execution instructions stored in the memory, thereby enabling the processor to execute the aforementioned parking planning method.

[0288] Figure 9 This is a structural schematic diagram of a parking planning device provided in an embodiment of this application. Figure 9 As shown, the parking planning device includes at least one processor 910 and a memory 920. The parking planning device also includes a communication component 930. The processor 910, memory 920, and communication component 930 are connected via a bus 940.

[0289] In the specific implementation process, at least one processor 910 executes computer execution instructions stored in memory 920, causing at least one processor 910 to execute a parking planning method as executed by the parking planning device as described above.

[0290] The specific implementation process of processor 910 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0291] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0292] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.

[0293] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0294] The above description of the functions implemented by the parking planning equipment and the main control equipment illustrates the solutions provided by the embodiments of the present invention. It is understood that, in order to achieve the above functions, the parking planning equipment or the main control equipment includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present invention.

[0295] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the parking planning method described above.

[0296] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0297] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in a parking planning device or a main control device.

[0298] This application also provides a computer program product, which includes a computer program stored in a readable storage medium. At least one processor of the parking planning device can read the computer program from the readable storage medium, and the at least one processor executes the computer program to cause the parking planning device to perform the scheme provided in the above embodiments.

[0299] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0300] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A parking planning method, characterized in that, include: Obtain a full dataset of information about the parking lot, which includes static topology information and dynamic real-time information; Based on the static topology information and the dynamic real-time information, the operating status information within the parking lot is determined; Receive a service request sent by the vehicle controller, and send the static topology information to the vehicle controller according to the service request; The system receives a decision assistance request sent by the vehicle controller and sends the operating status information to the vehicle controller at a preset period according to the decision assistance request, so that the vehicle controller can generate candidate paths and determine target paths based on the static topology information and the operating status information, and control the vehicle to perform parking actions based on the target paths.

2. The method according to claim 1, characterized in that, Determining the operational status information within the parking lot includes: Construct a topological map of the parking lot based on static topological information; Dynamic real-time information is mapped onto the topology map, and a real-time global situation map of the field is generated through spatiotemporal alignment, which serves as the operational status information.

3. The method according to claim 1, characterized in that, Sending the static topology information includes: Parse the service request to obtain vehicle size parameters; Filter out passable areas and available parking spaces that meet the vehicle size parameters from static topology information; The filtered static topology information is sent to the vehicle-side controller.

4. A parking planning method, characterized in that, include: In response to a parking request initiated by a user, a service request containing vehicle size parameters is sent to the parking lot. Receive static topology information sent by the field terminal in response to the service request; Send a decision assistance request to the site and receive operation status information sent by the site in response to the decision assistance request at a preset period. The operation status information is determined by the site based on the full information dataset of the parking lot. The full information dataset includes the static topology information and dynamic real-time information. Based on the static topology information and the running status information, multiple candidate paths are generated; The target path is determined by comprehensively analyzing the multiple candidate paths. Based on the target path, control the vehicle to perform a parking maneuver.

5. The method according to claim 4, characterized in that, The control of the vehicle to perform parking actions includes: Acquire local perception data collected by vehicle-mounted sensors; Local sensing data is fused with operational status information to generate fused environmental information; Based on the fused environmental information and target path, the vehicle is controlled to perform a parking maneuver.

6. The method according to claim 5, characterized in that, The method of controlling the vehicle to perform a parking action also includes: Based on the fused environmental information, local dynamic obstacle avoidance planning is performed on the target path to generate a target path containing a local obstacle avoidance trajectory. Based on the target path containing the local obstacle avoidance trajectory, control the vehicle to perform a parking maneuver.

7. The method according to claim 4, characterized in that, Determining the target path includes: Acquire user historical behavior data and site service resource information; The multiple candidate paths are scored based on the user's historical behavior data and the site service resource information; The candidate path with the highest score is determined as the target path.

8. The method according to claim 7, characterized in that, Also includes: During the vehicle's journey along the target path, the changes in the field service resource information are monitored. When the changing state satisfies the match between the idle resources at the site and the current service needs predicted based on the user's historical service list, service recommendation information is generated; Service recommendations are displayed to users through the in-vehicle interactive terminal.

9. The method according to claim 8, characterized in that, After displaying service recommendation information to the user via the in-vehicle interactive terminal, the method further includes: In response to the user's confirmation of the service recommendation information, a service reservation request is generated; The service reservation request is sent to the site.

10. A parking planning device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 3, or the method as described in any one of claims 4 to 9.

Images