WO2024182875A1

WO2024182875A1 - Systems and methods for a connected frenet frame cav planning platform

Info

Publication number: WO2024182875A1
Application number: PCT/CA2023/050289
Authority: WO
Inventors: Keqi Shu; Amir Khajepour; Weisen SHI; Ngoc Dung DAO
Original assignee: Huawei Technologies Canada Co., Ltd.
Priority date: 2023-03-06
Filing date: 2023-03-06
Publication date: 2024-09-12

Abstract

A method for planning paths of a connected autonomous vehicle (CAV) include receiving, by the local controller, from a global center, road topology information of a road network and a current location and a destination of the CAV. Also, receiving, by the local controller, from a roadside unit (RSU), perception information in a vicinity of the CAV. Then, constructing, by the local controller, using the current location, the destination, the perception information, and the road topology information, a scenario including route planning for the CAV on the road network in an area including the RSU. Generating, by the local controller, a plurality of waypoints connecting the destination of the CAV with the location of the CAV and interpolating a reference path from the plurality of waypoints. Then sending, by the local controller, to controllers of the CAV and to the RSU, information of reference paths to be followed by CAV.

Description

SYSTEMS AND METHODS FOR A CONNECTED FRENET

FRAME CAV PLANNING PLATFORM

TECHNICAL FIELD

[0001] This invention pertains generally to autonomous vehicles, and in particular to methods and systems for planning paths for of connected autonomous vehicles (CAVs).

BACKGROUND

[0002] Autonomous vehicles (AV) are self-driving or driver-less vehicles that are cable of driving without human input and are gaining popularity as solutions for future transportation needs. A key challenge in the development viable of AVs is to ensure the safe operation of the AV in a variety of conditions. To improve AV traffic safety overall, one approach is for AVs to be connected together through communication networks and for the AVs to operate as a group, thereby allowing AVs to better anticipate traffic conditions and to increase safety for AVs and for other traffic participants (TP) such as other vehicles, pedestrians, and other road users. With connectivity introduced to the traffic system, uncertainties in driving intension, surrounding TPs’ trajectories’ prediction, etc. are greatly decreased which as a result improves the traffic performance of the whole system. Thus, developing good CAV operation methods and systems is essential for their success in the market and with regulatory authorities.

[0003] Trajectory planning methods for CAVs can be very different from those of traditional AVs. For CAVs, more than one AV must typically be considered, and a trajectory or path planning method should consider cooperation between CAVs, as well as driving safety and driving efficiency. Maintaining safe distances between vehicles is already a difficult task, and anticipating an efficient trajectory for each vehicle significantly increases the difficulty level.

[0004] Among CAV planning application scenarios being considered, highway planning is one of the most common ones, as it is more likely to be implemented in real-world applications, because of the closed-road nature of a highway, i.e., its lower number of intersections. Highways scenarios include lane changes, on-ramp and off-ramp driving, and other tasks where the possibility of overlapping of CAB paths exists. To improve safety between highway vehicles, cooperation, competition, or both can be considered, and in either case, appropriate CAV planning methods are essential. [0005] Path planning algorithms may be implements in a variety of devices such as in the CAVs themselves, in roadside units, or in area controllers. Each of these devices may include computing resources, and especially in the case of the CAV, they have limited computing and memory resources. This, and the situation that as the number of CAVs increases and the speed at which the CAV travels increases, the complexity of the path generation problem increases while the amount of time available to produce a solution decreases, means that existing solutions may fail to produce reliable solutions in the limited amount of time available.

[0006] Therefore, there is a need for improves methods and systems to address the problem of designing a framework that can, considering all CAVs and other TPs in a scenario, find a globally optimized trajectory solution in real-time to ensure that safe travel of CAVs and other TPs, that obviate or mitigate limitations of the prior art.

[0007] This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

SUMMARY

[0008] Embodiments of the present disclosure provide hierarchical systems and methods for planning paths for CAVs that may produce optimal or close to optimal solutions in real-time given a reasonably large number of CAVs travelling at highway speeds. The system may include combinations of elements including global centers, local controllers, roadside units (RSUs), and groups of CAVs and take into account other non-connected vehicles, pedestrians, and other obstacles, and road topology. Path finding methods may be distributed among system elements in a hierarchical fashion, sharing information, and balancing computing resources.

[0009] According to an embodiment of the present disclosure, there is provided a method for planning paths of a connected autonomous vehicle (CAV). The method includes receiving, by the local controller, from a global center, road topology information of a road network. Also, receiving, by the local controller, from a roadside unit (RSU), perception information in a vicinity of the CAV. Receiving, by the local controller, from the global center, a current location and a destination of the CAV. Then, constructing, by the local controller, using the current location, the destination, the perception information, and the road topology information, a scenario, the scenario including route planning for the CAV on the road network in an area including the RSU. Generating, by the local controller, a plurality of waypoints connecting the destination of the CAV with the location of the CAV, and interpolating, by the local controller, a reference path from the plurality of waypoints. Then, sending, by the local controller, to controllers on-board the CAV and to the RSU, information of reference paths to be followed by the CAV.

[0010] According to an embodiment of the present disclosure, there is provided a method for planning a path of a connected autonomous vehicle (CAV). The method includes sending, by a roadside unit (RSU), to a local controller, perception information in a vicinity of the CAV. Also, receiving, by the RSU, from the local controller, a reference path to be followed by the CAV from a current location of the CAV to a destination of the CAV. Then generating, by the RSU, from the reference path, a plurality of candidate paths, by applying an offset to the reference path, and selecting a selected path from the plurality of candidate paths.

[0011] According to an embodiment of the present disclosure, there is provided a method for planning a path of a connected autonomous vehicle (CAV). The method includes sending, by the CAV, to a local controller, perception information in a vicinity of the CAV. Also, receiving, by the CAV, from the local controller, a reference path to be followed by the CAV from a current location of the CAV to a destination of the CAV. Then, generating, by the CAV, from the reference path, a plurality of candidate paths, by applying an offset to the reference path, and selecting a selected path from the plurality of candidate paths.

[0012] In further embodiments, the plurality of candidate paths are generated by applying longitudinal and lateral offsets to the reference path.

[0013] Embodiments further include, sending, by the RSU, to a controller on-board the CAV, the selected path.

[0014] In further embodiments, the reference path is based on a scenario including route planning for the CAV on a road network in an area including the RSU. The scenario is constructed by the local controller based on the current location, the destination, the perception information, and road topology information received by the local controller from a global center.

[0015] In further embodiments, the reference path is generated, by the local controller, from a plurality of waypoints connecting the destination of the CAV with the location of the CAV.

[0016] In further embodiments, the reference path is generated from the plurality of way points by a polynomial interpolation of the plurality of way points.

[0017] In further embodiments, the perception information includes additional perception information received from the CAV. [0018] In further embodiments, the selected path is selected so that the selected path does not cause a second CAV to come within a minimum safety distance to the CAV.

[0019] In further embodiments, the road topology information is based on traffic flow monitoring data and map data available to the global center.

[0020] In further embodiments, the traffic flow monitoring data comprises traffic flow information at a location of the road network.

[0021] In further embodiments, the perception information includes information associated with one of: an unconnected traffic participants including a pedestrian, a cyclist, or an animal; an unconnected vehicle; or an obstacle on along the path.

[0022] In further embodiments, the plurality of candidate paths form a group of Frenet frames. [0023] In further embodiments, a cost function is evaluated for each of the plurality of candidate paths are generated with the selected path being selected based on a lowest calculated cost.

[0024] In further embodiments, the cost function evaluation includes one of any of the following factors: a penalty of a collision involving the CAV, a lateral offset of the CAV, or [0025] a difference in a speed of the CAV and a speed limit along a candidate path.

[0026] In further embodiments, each of the plurality of waypoints is positioned at one of the following locations: a start of a lane change, an end of a lane change, a location where the number of lanes changes, or a location around an obstacle along the path.

[0027] According to an embodiment of the present disclosure, there is provided an apparatus including a processor and a non-transitory memory for storing instructions that when executed by the processor cause the apparatus to be configured to be operable to perform any of the methods described herein.

[0028] Technical benefits of embodiments include filtering possible combinations of paths for each CAV to limit the number of paths to be considered by the processing units or controllers. As such, real-time performance can be guaranteed, and planning results improved.

[0029] Furthermore, with methods described herein, the number of lane changes required, and the number of interactions between vehicles can be lower, thus improving, the overall performance of a CAV fleet in traffic.

[0030] Embodiments have been described above in conjunction with aspects of the present invention upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Fig. 1 illustrates a CAV planning system as a three-layer hierarchy, according to an embodiment.

[0032] Fig. 2 illustrates how waypoints can represent a highway scenario, according to an embodiment.

[0033] Fig. 3 illustrates a scenario where the number of lanes changes from 5 to 4, according to an embodiment.

[0034] Fig 4 demonstrates level 3 planning according to an embodiment. Two sets of reference paths, a set for each of two CAVs, are shown.

[0035] Fig. 5a illustrates a scenario where two middle lanes are closed and two side lanes are available, as can be processed with a method according to an embodiment. Obstacles are blocking lanes such that some CAVs must change lanes. The times taken for each CAV 120 to drive past the scenario can be recorded and compared with the results of alternative methods, and results have shown that travel time can be decreased by as much as 15%.

[0036] Fig. 5b is a graph showing a result of applying a method according to an embodiment, to the scenario of Fig. 5a.

[0037] Fig. 6a illustrate another scenario that was solved with a method according to an embodiment, namely where a four-lane highway becomes a three-lane highway.

[0038] Fig. 6b illustrates the paths resulting from applying a method according to embodiments to the scenario of Fig 6b.

[0039] Fig. 7 is a signal flow diagram illustrating the planning of a path for a CAV according to an embodiment.

[0040] Fig. 8 is a block diagram of an electronic device illustrated within a computing and communications environment that may be used for implementing the systems and methods disclosed herein.

[0041] It will be noted that throughout the appended drawings, like features may be identified by like reference numerals. DETAILED DESCRIPTION

[0042] Embodiments of the present disclosure provide hierarchical systems and methods for planning paths for CAVs that may produce optimal or close to optimal solutions in real-time given a reasonably large number of CAVs travelling at highway speeds, such as at the speed of traffic lower than the posted speed limits. The system may include combinations of elements including global centers, local controllers, roadside units (RSUs), and CAVs with on-board controllers. Elements of the system, such as global centers, local controllers, RSUs and CAVs with on-board controllers may be optionally used depending on individual situations and locations. Groups of CAVs may take into account other non-connected vehicles, pedestrians, and other obstacles, as well as road topology detected by or known to any of the elements of the system. Path (which may also be referred to as trajectories) finding methods may be statically or dynamically distributed among system elements in a hierarchical fashion, sharing information, and balancing computing resources as required by each situation.

[0043] As used herein, a CAV may be a vehicle that is in communication with at least one other CAV, and possibly in communication with at least one RSU. CAVs can be operated collectively as a fleet, i.e., in a group of CAVs, and paths of each CAVs may be coordinated with other CAVs as well as other, non-connected vehicles, pedestrians, and other obstacles. As used herein, a scenario refers to a situation of planning routes for one or more CAVs on a particular set of roads or highways, in an area serviced by one or more local controllers. The scenario may also include one or more RSUs. Road topology information for the set of roads or highways is available from a global center. Each CAV in the scenario has a local destination (within the area) and the produces paths for each CAV to facilitate it reaching its destination.

[0044] As known in the art, a Frenet frame is a reference frame centered at a position along a predefined path. Instead of defining the position of a vehicle in Cartesian coordinates, its position can be defined as a position on a fixed path. For example, on a given path, a position can be identified by a parameter “s” away from a reference starting point. Such position can later be mapped into Cartesian coordinates. More formally, a point of a curve in the Frenet frame could be represented by a triplet of three mutually orthogonal unit vectors; a tangent vector (tangential to the curve), a normal vector (in the direction of the curve), and a binormal vector being the cross product of the tangent vector and the normal vector.

[0045] As used herein, model predictive control (MPC) is a planning method that generates an optimized solution for a problem for a certain amount of time frame, then performs the optimized solution at the first time frame, and proceeds to the next time frame to further optimize the solution of the new first time frame.

[0046] As used herein, road topology information may include any information at a global (within an area of interest) scale related to monitoring and controlling traffic flow. Road topology information also includes road and map information. Traffic flow information may include monitoring traffic flow (number of TPs and their direction of travel) into and out of any number of nodes along roads in the area of interest and include bottleneck detection in order to decide which road(s) a single CAV or a group of CAVs should take.

[0047] As used herein, perception information may include any information related to unconnected (not in communication with the global center, local controller, RSU, or CAV) TP. Unconnected TPs includes, but is not limited to, include pedestrians, cyclist, and animals.

[0048] As used herein, mixed traffic is traffic that includes human-driven vehicles as well as autonomous vehicles. A bottle neck may be a point or region, in a highway scenario, where traffic is particularly dense and slow. A traffic participant (TP), in a traffic scenario, can be an autonomous vehicle, or a human-driven vehicle such as a motor vehicle, a cyclist, a pedestrian, etc.

[0049] Embodiments include a hierarchical CAV planning framework to enable safe and efficient driving. Methods in the framework may work in a centralized manner to avoid vehicles stuck in local optimal of the solution space. At the same time, to ensure the real time performance of the system, methods take advantage of the connected hardware infrastructure and the connected nature of the entire system so that the computational load is divided into high-level tasks and low-level tasks and assigned to different infrastructure units as well as onboard CAV controllers.

[0050] Methods may utilize Frenet frames. Candidate paths may form a group Frenet frame in order that the method does not have to consider all the possible combinations of paths of each CAV, and only consider the candidate path combinations that are sound. In this way, required computing resources are reduced, real-time performance may be achieved, and the planning results may improve. The path planning methods may include a “group Frenet frame” planner that which each CAV generates several optional paths based on a reference trajectory and evaluates them as a whole. Only the paths that do not overlap will be available for selection and this ensures that the vehicles do not collide with each other.

[0051] In embodiments, three layers may be used for CAV path planning. The layers which are related to the CAV system structure may include a first layer, operated on a global scale to monitor and control the traffic flow at the highest level, a second layer, working at the local controller level and generating long-term candidate paths for each CAV to follow, and the third layer, doing short-term real-time planning for each CAV to enable them to have collision-free paths, and at the same time ensuring that the paths offer good efficiency. In embodiments, the third layer may include one or more RSUs in a vicinity of the CAVs and local controllers incorporated into each CAV.

[0052] Methods and systems according to embodiments may consider all TPs in a scenario (CAVs and other TPs in a local area) and offer the technical benefits of finding an optimized trajectory solution close to globally optimal for all CAVs, enabling real-time planning, and ensuring that safe distances are kept between CAVs, TPs, and other obstacles.

[0053] A CAV planning system according to embodiments can be in communication with roadside infrastructure, such as RSUs. A roadside unit (RSU) can, for example, provide onsite, perception information of non-connected vehicles and other obstacles. It can also provide enhanced computational power by processing a planning method in coordination with a computer or controller on board any of the CAVs in a CAV fleet. For example, an RSU can be used to enhance a user’s collision warning, by detecting obstacles unknown to a CAV and sending a warning to the CAV earlier than otherwise. This can improve the overall safety of a CAV system. An RSU can detect and obtain information about the status of other vehicles at an intersection, including human-driving vehicles, and help anticipate the trajectories of any of the TPs.

[0054] With respect to planning and decision-making frameworks for CAVs in highway scenarios, it is a concern to ensure the safety of all TPs, or as many TPs as possible. To do this, the distances between each CAV and each TP need to be kept at a minimum safe value. This feature is one of the most important ones for a CAV planner, and requires attention. From a safety perspective, methods according to embodiments include a planner with which each vehicle generates several optional paths based on a reference trajectory and evaluates them as a whole. Since each path can be expressed as a set of Frenet frame trajectories, and the paths collectively form a group of paths, the planner can refer to a “group Frenet frame” planner. A method can limit the available paths to those from different CAVs that do not overlap, i.e., those paths that would not cause collisions.

[0055] Fig. 1 illustrates a CAV planning system as a three-layer hierarchy, according to an embodiment. A global center 105 monitors traffic flow in a large geographic area, which may include a city, a town, a rural area, etc., and then, sends data about traffic flow down to one or more local controllers 110, so the local controllers 110 can plan reference paths in more details. RSUs 115 are located along roads and are in communication with local controllers 110 and CAVs 120. In each CAV 120, an on-board, CAV controller or planner is located. Real-time planning of paths for CAVs 120 may be performed by RSU 115, CAV 120, or the processing may be distributed between one or more RSUs 115 and one or more CAVs 120.

[0056] The first layer 125 includes one or more global centers 105. This is a wide-area or wide- range control center monitoring traffic flow in a large area, potentially over a large, for example a thousand square-kilometer area. Inputs to this layer includes map information and traffic flow information. Global center 105 may output road topology information including route information and transmit the road topology information to the local controllers 110.

[0057] From a functional perspective, the three layers may work as a single domain to perform their intended role. At the first layer, the global center 105 can obtain general road map information for highway network; a highway, a road, or a combination of many highways and roads in the geographic area. The highway network can be simple or complex and can contain highway segments which, in total, can be hundreds or thousands of kilometers long. The first layer may also receive traffic information from local controllers. The global center 105 can work as a high level coordinator to monitor main road merges, including on-ramp traffic and off-ramp traffic, and bottlenecks to limit the number of reference paths each CAV could take. For example, for a CAV to get from a point A to a point E, there can be two options: path A- B-E and path A-C-D-E. If the global center anticipates a high probability of a bottleneck occurring soon, at a location between a location of the CAV and point B, then the global center can select path A-C-D-E to avoid the potential bottleneck. In an embodiment, a bottleneck can be characterized by the number of TPs coming into an observation zone from different directions, and the number of TPs leaving an observation zone towards different destinations. In other embodiments, other criteria may be used to identify a bottleneck, such as an accident, a broken down vehicle, a special event occurring in an area, etc.

A CAV planning method can include a layer 1 global center 105 The global center 105 can be configured to send information such as road geometry or topology information to one or more layer 2 local controllers 110.

[0058] The second layer 130 includes one or more local controllers 110. These are computing centers located in different regions of the area. In embodiments, there may be only one local controller 110 in an area. In other embodiments, there may be multiple local controllers 110 in the same area to improve performance or to provide redundancy. Inputs to a local controller 110 includes road geometry or topology information from a global center 105 and traffic information from roadside units (RSUs) 115 under their control or associated with the local controller 110. Local controllers 110 include the function of extracting road geometry information, generating waypoints, selecting waypoints, and generating reference paths. Outputs may include a set of reference paths for each CAV 120, which are transferred to onboard planners or controllers of respective CAVs 120.

[0059] A layer 2 local controller 110 is able to generate a set of reference paths for each CAV in its region, each region the same or smaller than the area monitored by a global center 105. In an example, a local controller 110 can be located in a region of a large city where many CAVs travel, and be in communication with a global center 105. A local controller 110 can consider road geometry information and other information to generate a set of reference paths for each CAV 120. In a highway scenario, road geometry information can be represented as waypoints, and a detailed path can be obtained by interpolating the waypoints with polynomials. Waypoints can include points where road geometry changes, and points where lane changes are possible.

[0060] The third layer 135 is responsible for preventing collisions and tracking CAVs, and includes the RSUs 115 and the on-board controller in the CAVs 120 (each CAV includes a controller and on-board planner functionality). Each RSU 115 may receive information from its local controller 110 and makes decisions cooperatively with the CAVs 120. Input for the third layer includes reference paths from a local controller 110, and output includes a selected, optimized path for the CAVs thereby implementing real-time behavior of the CAVs.

[0061] Fig. 2 illustrates how waypoints 210 can be used to represent a highway scenario, according to an embodiment. Each CAV 120 may provide a local destination 205 to an RSU 115. The destination 205, or information relevant to the destination, may then be transferred to a local controller 110, and subsequently to the global center 105. The destination waypoints 205 are represented as black dots. Using road topology information and the destination waypoints 205, the local controller 110 may generate waypoints 210, represented as white dots, such as white dot 210, between the CAVs 120 position and their destinations way points 205. Using the waypoints 210, a local controller 110 can generate an interpolated path between waypoints and the destination, such as by fitting a polynomial, cubic polynomial, or other function, to generate candidate paths, represented by dotted lines 220. In Fig. 2, candidate paths, which may be mathematically represented as smooth curves, are illustrated as dotted vectors, which may be referred to as reference paths. As described herein, using information from the level 3 layer 135, the candidate paths can also be generated to avoid obstacles 215.

[0062] In embodiments, assumptions can be made based on a driving criteria, such as safe manoeuvring, and rules may be generated to capture those assumptions in generated CAV paths. For example, a lane change maneuver can be limited to moving aside no further than to one adjacent lane per maneuver. To do this, three waypoints can be sufficient (moving aside two lanes in one maneuver might require more than three waypoints). Several waypoint combinations will be possible for each vehicle, but by assigning heuristics to each waypoint combination, an optimal selection can be made from the plurality of candidate paths.

[0063] In an example, a local controller 110 can be a powerful computing center located in a region of a large city where there is significant traffic, i.e., includes a large number of TPs. The local controller can generate reference paths for each TP, each reference path based on a polynomial interpolation of waypoints, and are transferred to Frenet frames. Given the reference paths for each CAV, RSUs 115 and CAV 120 controllers can generate candidate paths of each CAV by considering lateral and longitudinal offsets from the reference path in the Frenet frame, then they may select a path for each CAV such as to prevent collisions and optimize their path.

[0064] In other words, the local controller 110 may receive road topology information from a global center 105 and generates waypoints. After that, the local controller 110 may consider all possible combinations of waypoints in as a group and use mathematical techniques, such as cubic polynomial models, to generate reference paths given the selected waypoints along the paths. The reference path of each CAV may then be sent to RSU 115 and CAVs 120 to generate candidate paths considering longitudinal and lateral offsets. Then the RSU 115 selects the best candidate path combination for each CAV 120. The selected combination of paths represents an optimized solution to the initial problem. An example of a non-selected combination of paths, would be a combination of two paths, for two respective CAVs, that brings the two CAVs to change lanes, and to change back to their original lanes.

[0065] In embodiments, the RSUs 115 and on-board controllers of CAVs 120 may select, for each CAV 120, a combination of candidate paths that is considered optimal, not only for the corresponding CAV, but for a plurality of CAVs occupying the same road section during a similar time interval.

[0066] At the third layer 135, each CAV controller can generate real-time, short-term actions for the CAV 120. An RSU 115 is a unit with perception hardware able to obtain information from both CAVs, unconnected TPs (including pedestrians, cyclists, animals, etc.), and other obstacles. An RSU can also communicate and share information with other CAVs. If its computing capacity is sufficient, an RSU can also be configured to cover several nearby intersections or other features of the road or highway. [0067] To generate suitable waypoints according to embodiments, a local controller 110 may consider road topology information from the global center 105, as well as local traffic information from RSUs 115 and CAV planners 120, including perception information received from RSUs 115, local road information and local vehicle information, to construct a detailed local map. The local controller 110 can store detailed local map information as tuples and generate waypoints defining a scenario.

[0068] Fig. 3 illustrates a scenario where the number of lanes changes from 5 to 4 between column 4 and column 5. Waypoints 210 on ahighway section 305 are indicated by white circles and can be used to indicate particular features of the road. A local controller 110 can generate, readjust, or allocate waypoints, based on way points received from the global center 105 and further details obtained from RSUs 115 or CAVs 120. Examples of further details include details of the merging zone (between columns i = 4 and i = 5), and obstacles 215 (column i = 2, lanes 2 to 4). The location of a way point for a CAV 120 can also be adjusted based on the speed of the CAV passing by a way point. For a CAV having a higher speed for example, the distance between its waypoints can be further apart, and vice versa. The distance or spacing between waypoints may be used to define a resolution, though it is preferrable that critical points of the road remain identified by a sufficient number of waypoints suitably placed. Waypoints may be distributed to account for a higher CAV speed, the distance it takes for a CAV to change from one lane to another, obstacles, road conditions, etc. Waypoints generated around on-ramps, off-ramps, a location where lane changes frequently occur, obstacles, and other road features can be generated in a similar manner.

[0069] After a local controller 110 has generated waypoints as above, each CAV controller can select or adjust waypoints along the road to generate initial reference paths that consider other CAVs.

[0070] Over a distance, a vehicle may only be permitted to change one lane at a time (i.e., to an adjacent lane). This can restrict or limit the number of acceptable waypoints to choose from. Referring to Fig. 3, for a CAV at a waypoint (i, j) = (n, m), where n is the column z and m is the lane j, a list of acceptable subsequent waypoints can be limited in ways such as:

- the adjacent lane to the right: (n + 1, m + 1)

- the same lane: (n + 1, m)

- the adjacent lane to the left: (n + 1, m - 1)

[0071] For example, in the scenario of Fig. 3, given the waypoints 210 generated by the local planner 110 and available for the CAVs 120 starting at column i = 0, a CAV planner can select waypoints that avoid the obstacles 315. These include: - way points (1,1), then (2, 1 ) - path 310

- way points (1,2), then (2,1) - path 315

- waypoints (1,5), then (2,5) - path 320

[0072] Other waypoints, i.e., those in leading to the obstacles in column 2, such as waypoint (1,3), would not be available for selection or would not be selected. Waypoint combinations that are strange or unconventional can also be ignored, such as a waypoint combination that were to lead a CAV in a U-turn or a circle. With a sound selection, each CAV controller planner considers input from the other CAVs, and plans accordingly. The waypoints selected can then be used by a CAV controller to generate a group of candidate paths for each CAV, each candidate path defined with Frenet frames. For the CAV at (0,1), a group of reference paths includes path 310 and path 315 (represented with arrows in Fig. 3, but smoothed curves when fitted with polynomials and described with Frenet frames) from which candidate paths may be generated.

[0073] As an example, for a section of a highway, a local controller can generate waypoints specific to the highway section, traffic situation, and environmental situation. Each CAV planner can identify, for example, 20 waypoints (the number could be different for each CAV) that would avoid obstacles of the highway while progressing toward its direction. If there are 4 CAVs on the highway section, this would result in 160,000 possible waypoint combinations. By using heuristics, such as limiting the number of lane changes, minimizing the distance of each path, etc., the number of possible waypoint combinations can be reduced.

[0074] In embodiments, to select a path, a cost function Rp can be defined for each candidate path p, taking into account aspects such as collision, lateral offset, and speed offset. One such cost function can be expressed as:

where: i identifies a CAV; n is the number of CAVs;

Pi,_c is the penalty of a collision between the CAV i and an obstacle c on the highway section;

Poff is the lateral offset of the CAV i at time t;

Pv is the difference, at time t, between the highway section’s speed limit, and the speed of the i^th CAV. [0075] By minimizing a cost function such as the above, or a variation of it, the path associated with the lowest R_P value can be selected. This can result in selecting candidate paths that are short, and that also distribute the CAVs evenly on the highway section.

[0076] In an embodiments, status information for each TP (including CAVs) can be obtained via perception sensors of the RSUs. This information can then be shared to the CAVs. However, if there are too many TPs and the computational cost is too great for the nearest RSU, planning can be performed at the local controller 110 overseeing and in communication with the RSUs 115.

[0077] In embodiments, at level 2, the local controller 110 may map Cartesian coordinates to Frenet frame coordinates. That is, instead of considering a CAV’s position as a point on a plane, the position can be considered from the CAV’s perspective, where one coordinate is in the lateral direction to the reference path and the other coordinate is along the reference path. After a level 2 local controller 110 has generated a set of acceptable waypoints, a level 2 local controller can generate, for each CAV, a group of reference paths defined by Frenet frames.

[0078] To implement this method, a global center 105 may generate waypoints. A local controller 110 may select a set of waypoints considering local details and generate a set of reference paths from those waypoints. The RSU 115 and CAVs 120 can generate candidate paths from the reference paths, and can then minimize one or more lateral and longitudinal cost functions to select a path for each CAV 120, and the level 3 CAV 120 executes the selected path.

[0079] After a RSU 115 and a CAV 120 have generated a set of candidate paths, the RSU 115 and CAV 120 can evaluate each path, time step per time step (the columns, i, of Fig. 3), and determine whether the planned action is appropriate.

Fig. 4 demonstrates level 3 planning to select paths to fulfill a criteria, such as avoiding a collision, according to an embodiment. Illustrated, are two sets 406 of candidate paths (in section 405) that have been generated for CAVs 120 from the reference paths, which are the two long paths 414a and 414b extending from section 405 through section 410. Short term planning may be performed in section 405. A combination of two paths, one path per set of 406, is selected and evaluated after considering possible collisions at any point in time where the path will be used. Fig. 4 illustrates a case of a lane merge scenario and leads to the two paths 414a and 414b overlapping near point 415, though a valid solution would avoid a collision by having the two paths offset in time. The selected paths, 414a or 414b may be selected so that the selected path does not cause a second CAV, other TP, or other obstacle to come within a minimum safety distance to the CAV for which the path is selected. [0080] In embodiments, the paths 414a and 414b are calculated by one of more local controllers 110 at layer 2 130 as illustrated in Fig. 1.

[0081] A method according to embodiments can deal with many kinds of merging scenarios while keeping safe distances between the TPs. Given a highway system with multiple lanes, and a fleet of CAVs (a group of multiple CAVs acting together) driving autonomously on the road, the fleet of CAVs can encounter a scenario where one of the roads is blocked because of construction, and the fleet has to change its shape (where a shape is defined by an absolute or relative position, velocity, or acceleration of a group of CAVs) to pass the road safely. Some vehicles can move before or after other vehicles, and some vehicle can cooperate with others to pass through the blocked point. An RSU 115 can perceive or detect information about the road and other TPs, and transfer it to the CAVs. Then, given the road information, each CAV 120 can be assigned a selected path. Then, the path and speed can be generated using an onboard planner on both the CAVs 120 and RSU 115. Using the proposed methods, the CAVs 120 can pass the road with minimum energy cost while distances between CAVs 120 kept at safe minimums.

[0082] Another example of a scenario is where one or more middle lanes are closed and only one or two other lanes are available. In this scenario, there can be many interactions with other TPs. A path must be selected for each CAV, as well as a sequential order. In this case, it can be difficult to consider disconnected TPs and to evenly distribute the CAVs on the road section. [0083] Fig. 5a illustrates a scenario where two middle lanes are closed and two side lanes are available, as can be processed with a method according to an embodiment. Obstacles 215 are blocking lanes such that some CAVs 120 must change lanes to arrive at position 502. The times taken for each CAV 120 to drive past the obstacle 215 can be recorded and compared with the results of alternative methods.

[0084] Fig. 5b illustrates a graph showing a result of applying a method according to an embodiment, to the scenario of Fig. 5a. The result show that the reference paths 505, 510, 515 and 520 bypass the obstacles. Vehicles overcome the conflicting points where two lanes end, by cooperating with each other in a heuristic manner. Although some paths seem to cross at points 525 and 530, the CAVs go through these areas at different times (a time axis is not shown), as would be expected. Results have shown that travel time can be decreased by as much as 15% using scenarios such as those illustrated in Fig. 5b.

[0085] Figs. 6a illustrate another scenario that was solved with a method according to an embodiment, namely where a four-lane highway becoming a three-lane highway. For each CAV 120, a path (602, 604, 606, and 608) may be selected from a plurality of candidate paths to safely merge the CAVs from a four-lane formation to a three-lane formation. Figs. 6b illustrates the reference paths resulting from applying a method according to embodiments to the scenario of Fig 6b where the four CAVs merge from 4 lanes to three, and then further merge to 2 lanes.

[0086] Embodiments provide a sampling based planning algorithm that can allow for real-time determination of candidate paths for CAVs even as the complexity of the scenario increases. Embodiments produce candidate paths for groups of CAVs that take into account the plurality of CAVs operating concurrently and can take into account non-connected TPs, non-vehicular traffic, obstacles, and changing road topology. Methods describes herein may be effectively used in complex situations such as at road intersections where the number of TPs is greater and right-of-way ordering can be more complex than on a highway. Groups of candidate paths may be generated a hierarchical, centralized manner, where the number of candidate paths is limited to exclude unrealistic options and produce a small search space. Decreasing the number of candidate paths in a group of candidate paths may be achieved by generating group Frenet frame paths that sample the search space and limit their number. This provides a technical benefit over CAV planning frameworks where the paths of CAVs are planned in a distributed manner and can occupy a limitless search space, which can require too much computational time from a centralized planner. By generating candidate paths with group Frenet frames according to embodiments, the search space can be limited to be manageable with a given centralized planner, and still result in a near optimal solution. The centralized planner can reduce the number of conflicts between vehicles, which increases the travel efficiency of the CAVs.

[0087] CAV planning methods according to embodiments can also be used in highway scenarios, where the number of TPs increases or decreases, including on-ramp and off-ramp scenarios. A CAV planner can cause a CAV to automatically generate proper actions and movements to enable safe and efficient driving, and reduce fuel consumption by reducing braking frequency. Although CAV planning methods according to embodiments are focused on improving road traffic efficiency, they can be used to improve efficiency of non-traffic applications as well.

[0088] Fig. 7 is a signal flow diagram illustrating the planning of a path for a CAV according to embodiments. The diagram shows how signals are sent and received between a global center 105, a local controller 110, an RSU 115, and a CAV 120. The diagram also shows which component of the system performs processing. It is understood that there may be one or more of each of the global center 105, the local controller 110, the RSU 115, and the CAV 120. For example, a local controller 110 may receive perception information from multiple RSUs 115 and multiple CAVs 120. As well, reference path information may be sent to multiple RSUs in communication with multiple CAVs. A global center 105 or a local controller 110 may be implemented as distributed systems and distribute computing, data, and networking resources among them. If a CAV is travelling between regions or an RSU is situated near a border between regions, road topology information, or CAV 120 location and destination information may be obtained from more than one global center 105 or local controller 110. Various other combinations of global centers 105, local controllers 110, RSUs 115, and CAVs 120 may also be used as is known in the art. Though the signal flow and processing actions are shown in a sequence, it is also understood that the signals and actions may happen in any order once the required information is available. In some cases, previously received information may also be used, without being received, such as road topology information when road locations have not changed, or perception information when an obstacle has not moved or has moved an insignificantly small amount. The source of the perception information 704 or 706 depends on the situation and location of the CAVs 120. On major routes in dense, urban areas, there may be a large number of RSUs to provide perception information 704. However, in sparse, rural areas, no RSUs may be present. In cases, one or more CAVs will be present and may provide perception information 706 if equipped with the required sensors to provide this information. In box 710, local controller 110 uses the current CAV location and destination, the perception information (704, 706, or both 704 and 706), and the road topology information 702 to construct a scenario that includes route planning for the CAV 120 on the road network in an area including the RSU 115, if available, or in a vicinity of the CAV 120. In step 712 the local controller 110 generates a plurality of way points connecting the destination of the CAV 120 with the location of the CAV 120. One or more sets of waypoints may be generated to describe different reference paths between the CAV location and the CAV destination. In step 714, the local controller 110 my use interpolation techniques to produce a reference path from the plurality of way points. Where multiple set of waypoints have been generated, a reference path may be interpolated for each set. Reference path information 716 and 718 may be sent from the local controller 110 to any combination of RSUs 115 or CAVs 120 participating in the system. CAVs 120 include controllers to receive and process the reference path information. In embodiments, RSUs 115 or CAVs 120 receiving the reference path information may be the same RSUs that supplied perception information 704 or CAVs that supplied perception information 706, or be different. For example, a first RSU or a first CAV may supply perception information regarding a second CAV with the second CAV later receiving the reference path information 718. In step 720, the RSU 115 or the CAV 120 may apply offsets, such as longitudinal and lateral offsets, to the received reference path to generate a plurality of candidate paths for CAVs. In step 722, the RSU 115 or the CAV 120 may select a selected path from the plurality of candidate paths for use by the CAV. The assignment and distribution of steps 720 and 722 may be determined statically or dynamically, taking into account the number and processing resources of the RSU(s), and the CAV(s).

[0089] In embodiments, a local controller 110 received road topology information 702, from a global center 105. Some aspects of road topology information such as the location, direction, and width of a road will rarely change, while other information such as changes due to construction, may change frequently. The local controller 110 will also receive from the global center 105, information on the current location and destination of one, several, or all CAVs in an area 708. This information will be updated frequently as CAVs move within an area, enter the area, or exit the area. The local controller 110 also receives perception information 704 from one or more RSUs 115, perception information 706 from one or more CAVs 120, or perception information from both one or more RSUs 115 and from one or more CAVs 120.

[0090] Fig. 8 is a block diagram of an electronic device (ED) 770 that may be used for implementing the devices and methods disclosed herein, such as a system for determining a safe trajectory for a CAV. One or more electronic devices 770 may be used to implement global center 105, local controller 110, RSU 115, as well as controllers and planners found within CAV 120. The electronic device 770 typically includes a processor 754, such as a central processing unit (CPU), and may further include specialized processors such as a field programmable gate array (FPGA) or other such processor, a memory 756, a network interface 758 and a bus 760 to connect the components of ED 770. ED 770 may optionally also include components such as a mass storage device 762, and an I/O interface 768.

[0091] The memory 756 may comprise any type of non-transitory system memory, readable by the processor 754, such as static random-access memory (SRAM), dynamic random-access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In an embodiment, the memory 756 may include more than one type of memory, such as ROM for use at boot-up, and DRAM for program and data storage for use while executing programs. The bus 760 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus.

[0092] The electronic device 770 may also include one or more network interfaces 758, which may include at least one of a wired network interface and a wireless network interface. A network interface 758 may include a wired network interface to connect to a network 774, and also may include a radio access network interface 772 for connecting to other devices over a radio link. The network interfaces 758 allow the electronic device 770 to communicate with remote entities such as those connected to network 774.

[0093] The mass storage 762 may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus 760. The mass storage 762 may comprise, for example, one or more of a solid-state drive, hard disk drive, a magnetic disk drive, or an optical disk drive. In some embodiments, mass storage 762 may be remote to the electronic device 770 and accessible through use of a network interface such as interface 758. In the illustrated embodiment, mass storage 762 is distinct from memory 756 where it is included and may generally perform storage tasks compatible with higher latency but may generally provide lesser or no volatility. In some embodiments, mass storage 762 may be integrated with a heterogeneous memory 756.

[0094] In an embodiment, a system for determining a miss ratio curve can comprise at least one processor 754; a machine-readable memory 756 storing machine readable instructions which when executed by the at least one processor 754, configures the at least one processor 754 to implement the methods described in this disclosure. The network interface 774 and I/O interface 768 can also allow for storage and/or processing to occur externally.

[0095] In some embodiments, electronic device 770 may be a standalone device, while in other embodiments electronic device 770 may be resident within a data center. A data center, as will be understood in the art, is a collection of computing resources (typically in the form of servers) that can be used as a collective computing and storage resource. Within a data center, a plurality of servers can be connected together to provide a computing resource pool upon which virtualized entities can be instantiated. Data centers can be interconnected with each other to form networks consisting of pools computing and storage resources connected to each by connectivity resources. The connectivity resources may take the form of physical connections such as ethemet or optical communications links, and in some instances may include wireless communication channels as well. If two different data centers are connected by a plurality of different communication channels, the links can be combined together using any of a number of techniques including the formation of link aggregation groups (LAGs). It should be understood that any or all of the computing, storage, and connectivity resources (along with other resources within the network) can be divided between different sub-networks, in some cases in the form of a resource slice. If the resources across a number of connected data centers or other collection of nodes are sliced, different network slices can be created. [0096] Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.

Claims

1. A method for planning paths of a connected autonomous vehicle (CAV) comprising: receiving, by the local controller, from a global center, road topology information of a road network; receiving, by the local controller, from a roadside unit (RSU), perception information in a vicinity of the CAV; receiving, by the local controller, from the global center, a current location and a destination of the CAV; constructing, by the local controller, using the current location, the destination, the perception information, and the road topology information, a scenario, the scenario including route planning for the CAV on the road network in an area including the RSU; generating, by the local controller, a plurality of waypoints connecting the destination of the CAV with the location of the CAV; and interpolating, by the local controller, a reference path from the plurality of waypoints; sending, by the local controller, to controllers on board the CAV and to the RSU, information of reference paths to be followed by the CAV.

2. A method for planning a path of a connected autonomous vehicle (CAV) comprising: sending, by a roadside unit (RSU), to a local controller, perception information in a vicinity of the CAV; receiving, by the RSU, from the local controller, a reference path to be followed by the CAV from a current location of the CAV to a destination of the CAV; generating, by the RSU, from the reference path, a plurality of candidate paths, by applying an offset to the reference path; and selecting a selected path from the plurality of candidate paths.

3. A method for planning a path of a connected autonomous vehicle (CAV) comprising: sending, by the CAV, to a local controller, perception information in a vicinity of the CAV; receiving, by the CAV, from the local controller, a reference path to be followed by the CAV from a current location of the CAV to a destination of the CAV; generating, by the CAV, from the reference path, a plurality of candidate paths, by applying an offset to the reference path; and selecting a selected path from the plurality of candidate paths.

4. The method of any of claims 2 or 3, wherein the plurality of candidate paths are generated by applying longitudinal and lateral offsets to the reference path.

5. The method of any of claims 2 to 4, further including, sending, by the RSU, to a controller on-board the CAV, the selected path.

6. The method of any of claims 2 to 5 wherein the reference path is based on a scenario including route planning for the CAV on a road network in an area including the RSU, the scenario being constructed by the local controller based on the current location, the destination, the perception information, and road topology information received by the local controller from a global center.

7. The method of claim 6 wherein the reference path is generated, by the local controller, from a plurality of waypoints connecting the destination of the CAV with the location of the CAV.

8. The method of claim 7 wherein the reference path is generated from the plurality of waypoints by a polynomial interpolation of the plurality of waypoints.

9. The method of any of claim 2 to 8, wherein the perception information includes additional perception information received from the CAV.

10. The method of any of claims 2 to 9, wherein the selected path is selected so that the selected path does not cause a second CAV to come within a minimum safety distance to the CAV.

11. The method of any of claims 1 or claims 4 to 10, wherein the road topology information is based on traffic flow monitoring data and map data available to the global center.

12. The method of claim 11, wherein the traffic flow monitoring data comprises traffic flow information at a location of the road network.

13. The method of any of claims 1 to 12, wherein the perception information comprises information associated with one of: an unconnected traffic participants including a pedestrian, a cyclist, or an animal; an unconnected vehicle; or an obstacle on along the path.

14. The method of any of claims 2 to 13, wherein the plurality of candidate paths form a group of Frenet frames.

15. The method of any of claims 2 to 14, wherein a cost function is evaluated for each of the plurality of candidate paths are generated with the selected path being selected based on a lowest calculated cost.

16. The method of claim 15 wherein the cost function evaluation includes one of any of the following factors: a penalty of a collision involving the CAV, a lateral offset of the CAV, or a difference in a speed of the CAV and a speed limit along a candidate path.

17. The method of claim 1, wherein each of the plurality of way points is positioned at one of the following locations: a start of a lane change, an end of a lane change, a location where the number of lanes changes, or a location around an obstacle along the path.

18. An apparatus comprising: a processor; and a non-transitory memory for storing instructions that when executed by the processor cause the apparatus to be configured to be operable to perform any of the methods of claims 1 to 17.