CN109491377B

CN109491377B - DP and QP based decision and planning for autonomous vehicles

Info

Publication number: CN109491377B
Application number: CN201810745836.2A
Authority: CN
Inventors: 朱帆; 孔旗; 朱伟铖; 樊昊阳; 庄立
Original assignee: Baidu USA LLC
Current assignee: Baidu USA LLC
Priority date: 2017-09-11
Filing date: 2018-07-09
Publication date: 2022-07-08
Anticipated expiration: 2038-07-09
Also published as: CN109491377A; US20190079523A1; US10754339B2

Abstract

According to some embodiments, the system calculates the first trajectory based on the map and the route information. The system generates a path profile based on the first trajectory, the traffic rules, and the obstacle information describing the one or more obstacles perceived by the ADV. The system generates a speed profile based on the path profile, wherein the speed profile includes, for each obstacle of the plurality of obstacles, a decision to yield or exceed the obstacle. The system performs quadratic programming optimization on the path profile and the speed profile to identify the best path with the best speed. The system generates a second trajectory based on the optimal path and the optimal speed to autonomously control the ADV according to the second trajectory.

Description

DP and QP based decision and planning for autonomous vehicles

Technical Field

Embodiments of the present disclosure generally relate to operating an autonomous vehicle. More particularly, embodiments of the present disclosure relate to Dynamic Programming (DP) and Quadratic Programming (QP) based decision and planning for autonomous vehicles (ADV).

Background

Vehicles operating in an autonomous driving mode (e.g., unmanned) may relieve passengers, particularly the driver, from some driving-related responsibilities. When operating in an autonomous driving mode, the vehicle may be navigated to various locations using onboard sensors, allowing the vehicle to travel with minimal human interaction or in some cases without any passengers.

Motion planning and control are key operations in autonomous driving. However, motion planning and control may be open and may be difficult to optimize without some initial constraints. Furthermore, motion planning and control is applied in some cases to all types of vehicles that may be inaccurate and unstable.

Disclosure of Invention

A computer-implemented method of generating a driving trajectory for an autonomous vehicle is provided. The method comprises the following steps: calculating a first trajectory based on the map and the route information; generating a path profile based on the first trajectory, traffic rules, and obstacle information describing one or more obstacles perceived by the autonomous vehicle; generating a speed profile based on the path profile, wherein the speed profile includes, for each of the plurality of obstacles, a decision to make or exceed the obstacle; performing quadratic programming optimization on the path profile and the speed profile to identify an optimal path having an optimal speed; and generating a second trajectory based on the optimal path and the optimal speed to autonomously control the autonomous vehicle in accordance with the second trajectory.

According to an embodiment of the application, the path profile and the speed profile are iteratively generated using dynamic programming.

According to an embodiment of the application, the path profile comprises, for each obstacle decision encountered, a decision to let go, ignore or skim from the left or right of the encountered obstacle.

According to an embodiment of the present application, performing quadratic programming optimization on the path profile and the speed profile comprises: optimizing a first cost function using quadratic programming to generate a base point-side shift map based on the path profile; and optimizing a second cost function using quadratic programming to generate a base point-time map based on the speed profile.

According to an embodiment of the application, the base-side shift map is generated by forming one or more obstacles based on one or more obstacle decisions.

According to an embodiment of the application, the first cost function comprises a heading cost, a curvature cost and a distance cost.

According to an embodiment of the application, the second cost function comprises an acceleration cost, a jerk cost and a distance cost.

According to an embodiment of the present application, further comprising inserting a plurality of points, which are not present in the first track, into the second track based on the base point-side shift map and the base point-time map.

The present application also provides a non-transitory machine-readable medium having instructions stored thereon. The instructions, when executed by a processor, cause the processor to perform operations comprising: calculating a first trajectory based on the map and the route information; generating a path profile based on the first trajectory, traffic rules, and obstacle information describing one or more obstacles perceived by the autonomous vehicle; generating a speed profile based on the path profile, wherein the speed profile includes, for each of the plurality of obstacles, a decision to make or exceed the obstacle; performing quadratic programming optimization on the path profile and the speed profile to identify an optimal path having an optimal speed; and generating a second trajectory based on the optimal path and the optimal speed to autonomously control the autonomous vehicle in accordance with the second trajectory.

The present application also provides a data processing system, comprising: a processor; and a memory coupled to the processor to store instructions that, when executed by the processor, cause the processor to perform operations comprising: calculating a first trajectory based on the map and the route information; generating a path profile based on the first trajectory, traffic rules, and obstacle information describing one or more obstacles perceived by the autonomous vehicle; generating a speed profile based on the path profile, wherein the speed profile includes, for each of the plurality of obstacles, a decision to make or exceed the obstacle; performing quadratic programming optimization on the path profile and the speed profile to identify an optimal path having an optimal speed; and generating a second trajectory based on the optimal path and the optimal speed to autonomously control the autonomous vehicle in accordance with the second trajectory.

Drawings

Embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

FIG. 1 is a block diagram illustrating a networked system according to one embodiment.

FIG. 2 is a block diagram illustrating an example of an autonomous vehicle according to one embodiment.

Fig. 3A-3B are block diagrams illustrating an example of a perception and planning system for use with an autonomous vehicle, according to one embodiment.

FIG. 4 is a block diagram illustrating an example of a decision-making process and planning process in accordance with one embodiment.

FIG. 5A is a block diagram illustrating an example of a decision module according to one embodiment.

FIG. 5B is a block diagram illustrating an example of a planning module, according to one embodiment.

Fig. 6 is a block diagram illustrating a base-side shift map according to one embodiment.

Fig. 7A and 7B are block diagrams illustrating a base point-time diagram according to some embodiments.

FIG. 8 is a flow chart illustrating a method according to one embodiment.

FIG. 9 is a block diagram illustrating an example of a planning module, according to one embodiment.

FIG. 10 is a flow chart illustrating a method according to one embodiment.

FIG. 11 is a block diagram illustrating an example of a planning module, according to one embodiment.

Fig. 12A-12B are block diagrams illustrating a path cost module and a speed cost module, respectively, according to one embodiment.

FIG. 13 is a flow chart illustrating a method according to one embodiment.

FIG. 14A is a flow chart illustrating a method according to one embodiment.

FIG. 14B is a flow chart illustrating a method according to one embodiment.

FIG. 15 is a block diagram illustrating a data processing system in accordance with one embodiment.

Detailed Description

Various embodiments and aspects of the disclosure will be described with reference to details discussed below, and the accompanying drawings will illustrate the various embodiments. The following description and drawings are illustrative of the disclosure and are not to be construed as limiting the disclosure. Numerous specific details are described to provide a thorough understanding of various embodiments of the present disclosure. However, in certain instances, well-known or conventional details are not described in order to provide a concise discussion of embodiments of the present disclosure.

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the disclosure. The phrase "in one embodiment" is not necessarily all described in various places throughout this specification to refer to the same embodiment.

According to some embodiments, the ADV includes a decision and planning system that autonomously controls the ADV. Based on the starting location and the ending location, the system queries a routing service for a reference route and calculates a reference line for the ADV to drive from the starting location to the ending location. Based on perceived obstacles and traffic conditions around the ADV, the system determines a path decision and a speed decision to ignore, pass, yield, or exceed the obstacle according to traffic rules and/or conditions of the ADV. The system optimizes one or more reference lines as trajectories based on path decisions and speed decisions to plan when and where the vehicle should be at a particular point in time.

According to one aspect, the system calculates a first trajectory based on the map and route information. The system generates a Path Profile (Path Profile) based on the first trajectory, the traffic rules, and the obstacle information describing the one or more obstacles perceived by the ADV. The system generates a speed Profile (Space Profile) based on the path Profile, wherein the speed Profile includes, for each obstacle, a decision to yield or exceed the obstacle. The system performs quadratic programming optimization on the path profile and the velocity profile to identify an optimal path having an optimal velocity, and generates a second trajectory based on the optimal path and the optimal velocity, such that the ADV may be autonomously controlled based on the second trajectory. The second trajectory represents the first trajectory optimized using quadratic programming optimization.

According to another aspect, the system calculates a first trajectory based on the map and the route information. The system generates a path profile based on the first trajectory, the traffic rules, and obstacle information describing one or more obstacles perceived by the ADV, wherein the path profile includes, for each obstacle, a decision to give way or sweep from the left or right side of the obstacle. The system generates a speed profile based on the path profile according to the traffic rules. The system performs a gradient descent optimization based on the path profile and the velocity profile to generate a second trajectory representing the optimized first trajectory, and controls the ADV according to the second trajectory.

According to yet another aspect, the system generates a plurality of feasible decisions for tracking the ADV from the first location to the second location according to a set of traffic rules based on perception information that perceives a driving environment (including one or more obstacles) surrounding the ADV. The system calculates a plurality of trajectories based on a combination of one or more feasible decisions. The system calculates a total cost for each trajectory using a plurality of cost functions and autonomously controls the ADV by selecting the trajectory having the smallest total cost as the driving trajectory. The cost functions include a path cost function, a speed cost function, and an obstacle cost function.

Fig. 1 is a block diagram illustrating an autonomous vehicle network configuration according to one embodiment of the present disclosure. Referring to fig. 1, a network configuration 100 includes an autonomous vehicle 101 that may be communicatively coupled to one or more servers 103-104 through a network 102. Although one autonomous vehicle is shown, multiple autonomous vehicles may be coupled to each other and/or to servers 103-104 through network 102. The network 102 may be any type of network, such as a wired or wireless Local Area Network (LAN), a Wide Area Network (WAN) such as the Internet, a cellular network, a satellite network, or a combination thereof. The servers 103-104 may be any type of server or cluster of servers, such as a network or cloud server, an application server, a backend server, or a combination thereof. The servers 103 to 104 may be data analysis servers, content servers, traffic information servers, map and point of interest (MPOI) servers, or location servers, etc.

Autonomous vehicles refer to vehicles that may be configured to be in an autonomous driving mode in which the vehicle navigates through the environment with little or no input from the driver. Such autonomous vehicles may include a sensor system having one or more sensors configured to detect information related to the operating environment of the vehicle. The vehicle and its associated controller use the detected information to navigate through the environment. Autonomous vehicle 101 may operate in a manual mode, in a fully autonomous mode, or in a partially autonomous mode.

In one embodiment, autonomous vehicle 101 includes, but is not limited to, a perception and planning system 110, a vehicle control system 111, a wireless communication system 112, a user interface system 113, and a sensor system 115. Autonomous vehicle 101 may also include certain common components included in a common vehicle, such as: engines, wheels, steering wheels, transmissions, etc., which may be controlled by the vehicle control system 111 and/or the sensory and programming system 110 using a variety of communication signals and/or commands, such as, for example, acceleration signals or commands, deceleration signals or commands, steering signals or commands, braking signals or commands, etc.

The components 110-115 may be communicatively coupled to each other via an interconnect, bus, network, or combination thereof. For example, the components 110-115 may be communicatively coupled to one another via a Controller Area Network (CAN) bus. The CAN bus is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other in applications without a host. It is a message-based protocol originally designed for multiplexed electrical wiring within automobiles, but is also used in many other environments.

Referring now to fig. 2, in one embodiment, the sensor system 115 includes, but is not limited to, one or more cameras 211, a Global Positioning System (GPS) unit 212, an Inertial Measurement Unit (IMU)213, a radar unit 214, and a light detection and ranging (LIDAR) unit 215. The GPS system 212 may include a transceiver operable to provide information regarding the location of the autonomous vehicle. The IMU unit 213 may sense position and orientation changes of the autonomous vehicle based on inertial acceleration. Radar unit 214 may represent a system that utilizes radio signals to sense objects within the local environment of an autonomous vehicle. In some embodiments, in addition to sensing an object, radar unit 214 may additionally sense a speed and/or heading of the object. The LIDAR unit 215 may use a laser to sense objects in the environment in which the autonomous vehicle is located. The LIDAR unit 215 may include one or more laser sources, laser scanners, and one or more detectors, among other system components. The camera 211 may include one or more devices used to capture images of the environment surrounding the autonomous vehicle. The camera 211 may be a still camera and/or a video camera. The camera may be mechanically movable, for example, by mounting the camera on a rotating and/or tilting platform.

The sensor system 115 may also include other sensors, such as: sonar sensors, infrared sensors, steering sensors, throttle sensors, brake sensors, and audio sensors (e.g., microphones). The audio sensor may be configured to collect sound from an environment surrounding the autonomous vehicle. The steering sensor may be configured to sense a steering angle of a steering wheel, wheels of a vehicle, or a combination thereof. The throttle sensor and the brake sensor sense a throttle position and a brake position of the vehicle, respectively. In some cases, the throttle sensor and the brake sensor may be integrated into an integrated throttle/brake sensor.

In one embodiment, the vehicle control system 111 includes, but is not limited to, a steering unit 201, a throttle unit 202 (also referred to as an acceleration unit), and a brake unit 203. The steering unit 201 is used to adjust the direction or forward direction of the vehicle. The throttle unit 202 is used to control the speed of the motor or engine, which in turn controls the speed and acceleration of the vehicle. The brake unit 203 decelerates the vehicle by providing friction to decelerate the wheels or tires of the vehicle. It should be noted that the components shown in fig. 2 may be implemented in hardware, software, or a combination thereof.

Returning to fig. 1, wireless communication system 112 allows communication between autonomous vehicle 101 and external systems such as devices, sensors, other vehicles, and the like. For example, the wireless communication system 112 may be in direct wireless communication with one or more devices, or in wireless communication via a communication network, such as with the servers 103-104 through the network 102. The wireless communication system 112 may use any cellular communication network or Wireless Local Area Network (WLAN), for example, using WiFi, to communicate with another component or system. The wireless communication system 112 may communicate directly with devices (e.g., passenger's mobile device, display device, speaker within the vehicle 101), for example, using infrared links, bluetooth, etc. The user interface system 113 may be part of a peripheral device implemented within the vehicle 101, including, for example, a keypad, a touch screen display device, a microphone, and speakers, among others.

Some or all of the functions of the autonomous vehicle 101 may be controlled or managed by the perception and planning system 110, particularly when operating in an autonomous mode. The awareness and planning system 110 includes the necessary hardware (e.g., processors, memory, storage devices) and software (e.g., operating systems, planning and routing programs) to receive information from the sensor system 115, the control system 111, the wireless communication system 112, and/or the user interface system 113, process the received information, plan a route or path from the origin to the destination, and then drive the vehicle 101 based on the planning and control information. Alternatively, the sensing and planning system 110 may be integrated with the vehicle control system 111.

For example, a user who is a passenger may specify a start location and a destination of a trip, e.g., via a user interface. The perception and planning system 110 obtains trip related data. For example, the sensing and planning system 110 may obtain location and route information from an MPOI server, which may be part of the servers 103-104. The location server provides location services and the MPOI server provides map services and POIs for certain locations. Alternatively, such location and MPOI information may be cached locally in persistent storage of the sensing and planning system 110.

The perception and planning system 110 may also obtain real-time traffic information from a traffic information system or server (TIS) as the autonomous vehicle 101 moves along the route. It should be noted that the servers 103 to 104 may be operated by third party entities. Alternatively, the functionality of the servers 103-104 may be integrated with the perception and planning system 110. Based on the real-time traffic information, MPOI information, and location information, as well as real-time local environmental data (e.g., obstacles, objects, nearby vehicles) detected or sensed by sensor system 115, perception and planning system 110 may plan an optimal route and drive vehicle 101, e.g., via control system 111, according to the planned route to safely and efficiently reach a designated destination.

Server 103 may be a data analysis system that performs data analysis services for a variety of clients. In one embodiment, data analysis system 103 includes a data collector 121 and a machine learning engine 122. The data collector 121 collects driving statistics 123 from various vehicles (autonomous vehicles or regular vehicles driven by human drivers). The driving statistics 123 include information indicative of driving commands (e.g., throttle commands, brake commands, steering commands) issued at different points in time and the vehicle's response (e.g., speed, acceleration, deceleration, direction) captured by the vehicle's sensors. The driving statistics 123 may also include information describing the driving environment at different points in time, such as, for example, a route (including a start location and a destination location), an MPOI, road conditions, weather conditions, and so forth.

Based on the driving statistics 123, the machine learning engine 122 generates or trains a rule set, algorithm, and/or predictive model 124 for a variety of purposes. For example, server 103 may include routing service 125 to provide routing services (e.g., route and map information) to ADV 101. ADV 101 may request a reference route (e.g., an ideal route without obstacle information or traffic conditions) from routing service 125 by indicating a start location and an end location. The routing service 125 then returns the requested route. In one embodiment, returning to the reference route may include returning one or more tables, such as a reference point table and a road segment/lane table. Alternatively, route and map information may be downloaded and cached in the vehicle, which information may be used in real time.

The server 103 may generate a reference route, for example, the machine learning engine 122 may generate the reference route from map information (information such as a section of a road, a lane of the section of the road, and a distance from the lane to a curb). For example, a road may be divided into { A, B and C } sections or segments to represent three road segments. The three lanes of road segment A may be listed as { A1, A2, and A3 }. The reference route is generated by generating reference points along the reference route. For example, for a lane, the machine learning engine 122 may connect the midpoints of two opposing curbs or edges of the lane provided by the map data. Based on machine learning data representing collected data points at which the vehicle was driving on the lane at different points in time and the midpoint, the engine 122 may calculate the reference point by selecting a subset of the collected data points within a predetermined proximity of the lane and applying a smoothing function to the midpoint based on the subset of collected data points.

Based on the reference point or the lane reference point, the ADV receiving the reference point may generate a reference line by interpolating the reference point such that the generated reference line is used as a reference line for controlling the ADV on the lane. In some implementations, reference point tables and road segment tables representing reference lines are downloaded to the ADV in real-time so that the ADV can generate a reference line based on the geographical location and driving direction of the ADV. For example, in one embodiment, the ADV may generate the reference line by requesting routing services for the path segment using a path segment identifier representing the upcoming road segment ahead and/or an ADV-based GPS location. Based on the path segment identifier, the routing service may return to an ADV reference point table that contains reference points for all lanes of the road segment of interest. The ADV may consult a reference point of the lane of the path segment to generate a reference line for controlling the ADV on the lane. It should be noted that the above process is performed offline by the analysis server 103, wherein the reference point of the route is determined based on the route and the map information. However, the same data may be dynamically determined in real time within each vehicle, as will be described in further detail below.

Fig. 3A and 3B are block diagrams illustrating an example of a perception and planning system for use with an autonomous vehicle, according to one embodiment. The system 300 may be implemented as part of the autonomous vehicle 101 of fig. 1, including but not limited to the perception and planning system 110, the control system 111, and the sensor system 115. Referring to fig. 3A-3B, the awareness and planning system 110 includes, but is not limited to, a positioning module 301, an awareness module 302, a prediction module 303, a decision module 304, a planning module 305, a control module 306, and a routing module 307.

Some or all of modules 301 through 307 may be implemented in software, hardware, or a combination thereof. For example, the modules may be installed in persistent storage 352, loaded into memory 351, and executed by one or more processors (not shown). It should be noted that some or all of these modules may be communicatively coupled to or integrated with some or all of the modules of the vehicle control system 111 of fig. 2. Some of modules 301 to 307 may be integrated together into an integrated module. For example, the decision module 304 and the planning module 305 may be integrated into a single module.

The location module 301 determines the current location of the autonomous vehicle 300 (e.g., using the GPS unit 212) and manages any data related to the user's trip or route. The positioning module 301 (also referred to as a map and route module) manages any data related to the user's journey or route. The user may, for example, log in via a user interface and specify a starting location and a destination for the trip. The positioning module 301 communicates with other components of the autonomous vehicle 300, such as map and route information 311, to obtain trip related data. For example, the location module 301 may obtain location and route information from a location server and a map and poi (mpoi) server. The location server provides location services and the MPOI server provides map services and POIs for certain locations and may thus be cached as part of the map and route information 311. The location module 301 may also obtain real-time traffic information from a traffic information system or server as the autonomous vehicle 300 moves along the route.

Based on the sensor data provided by sensor system 115 and the positioning information obtained by positioning module 301, perception module 302 determines a perception of the surrounding environment. The perception information may represent what an average driver would perceive around the vehicle the driver is driving. Perception may include, for example, lane configuration in the form of an object (e.g., a straight lane or a curved lane), a traffic light signal, a relative position of another vehicle, a pedestrian, a building, a crosswalk, or other traffic-related indicia (e.g., a stop sign, a yield sign), and so forth.

The perception module 302 may include a computer vision system or functionality of a computer vision system to process and analyze images captured by one or more cameras to identify objects and/or features in an autonomous vehicle environment. The objects may include traffic signals, road boundaries, other vehicles, pedestrians, and/or obstacles, etc. Computer vision systems may use object recognition algorithms, video tracking, and other computer vision techniques. In some embodiments, the computer vision system may map the environment, track objects, and estimate the speed of objects, among other things. The perception module 302 may also detect objects based on other sensor data provided by other sensors, such as radar and/or LIDAR.

For each object, the prediction module 303 predicts the behavior of the object under the circumstances. The prediction is performed according to a set of map/route information 311 and traffic rules 312 based on perception data of the driving environment perceived at a certain point in time. For example, if the object is a vehicle at the opposite direction and the current driving environment includes an intersection, the prediction module 303 will predict whether the vehicle is likely to go straight ahead or likely to turn. If the perception data indicates that the intersection has no traffic lights, the prediction module 303 may predict that the vehicle may have to come to a complete stop before entering the intersection. If the perception data indicates that the vehicle is currently in a left-turn-only lane or a right-turn-only lane, the prediction module 303 may predict that the vehicle is more likely to make a left turn or a right turn, respectively.

For each subject, the decision module 304 makes a decision on how to treat the subject. For example, for a particular object (e.g., another vehicle in a crossing route) and metadata describing the object (e.g., speed, direction, turn angle), the decision module 304 decides how to encounter the object (e.g., cut, yield, stop, pass). The decision module 304 may make such a decision based on a rule set, such as traffic rules or driving rules 312, which may be stored in persistent storage 352.

Based on the decisions for each of the perceived objects, the planning module 305 plans a path or route and driving parameters (e.g., distance, speed, and/or turn angle) for the autonomous vehicle. In other words, for a given object, the decision module 304 decides what to do with the object, and the planning module 305 determines how to do. For example, for a given subject, the decision module 304 may decide to pass through the subject, while the planning module 305 may determine whether to pass on the left or right side of the subject. Planning and control data is generated by the planning module 305, including information describing how the vehicle 300 will move in the next movement cycle (e.g., the next route/path segment). For example, the planning and control data may instruct the vehicle 300 to move 10 meters at a speed of 30 miles per hour (mph), and then change to the right lane at a speed of 25 mph.

Based on the planning and control data, the control module 306 controls and drives the autonomous vehicle by sending appropriate commands or signals to the vehicle control system 111 according to the route or path defined by the planning and control data. The planning and control data includes sufficient information to drive the vehicle from a first point to a second point of the route or path at different points in time along the route or route using appropriate vehicle settings or driving parameters (e.g., throttle, brake, and turn commands).

In one embodiment, the planning phase is performed in a plurality of planning periods (also referred to as command periods), such as, for example, at intervals of every 100 milliseconds (ms). For each planning or command cycle, one or more control commands will be issued based on the planning and control data. That is, for every 100ms, the planning module 305 plans the next route segment or path segment, e.g., including the target location and the time required for the ADV to reach the target location. Alternatively, the planning module 305 may also specify a particular speed, direction, and/or steering angle, etc. In one embodiment, the planning module 305 plans a route segment or a path segment for the next predetermined time period (such as 5 seconds). For each planning cycle, the planning module 305 plans the target location for the current cycle (e.g., the next 5 seconds) based on the planned target location in the previous cycle. The control module 306 then generates one or more control commands (e.g., throttle control commands, brake control commands, steering control commands) based on the current cycle of the schedule and the control data.

It should be noted that the decision module 304 and the planning module 305 may be integrated as an integrated module. The decision module 304/planning module 305 may include a navigation system or functionality of a navigation system to determine a driving path of an autonomous vehicle. For example, the navigation system may determine a range of speeds and heading directions for enabling the autonomous vehicle to move along the following path: the path substantially avoids perceived obstacles while advancing the autonomous vehicle along a roadway-based path to a final destination. The destination may be set based on user input via the user interface system 113. The navigation system may dynamically update the driving path while the autonomous vehicle is running. The navigation system may combine data from the GPS system and one or more maps to determine a driving path for the autonomous vehicle.

The decision module 304/planning module 305 may also include a collision avoidance system or the functionality of a collision avoidance system to identify, assess, and avoid or otherwise overcome potential obstacles in the environment of the autonomous vehicle. For example, a collision avoidance system may implement a change in navigation of an autonomous vehicle by: one or more subsystems in the control system 111 are operated to take a turning maneuver, a braking maneuver, etc. The collision avoidance system may automatically determine a feasible obstacle avoidance maneuver based on surrounding traffic patterns, road conditions, and the like. The collision avoidance system may be configured such that no turn-changing maneuvers are taken when other sensor systems detect vehicles, building obstacles, etc. located in adjacent areas into which the autonomous vehicle will change direction. The collision avoidance system may automatically select maneuvers that are both available and that maximize the safety of the occupants of the autonomous vehicle. The collision avoidance system may select an avoidance maneuver that is predicted to cause a minimum amount of acceleration to occur in a passenger compartment of the autonomous vehicle.

The routing module 307 may generate a reference route, for example, from map information (such as road segments, lanes of the road segments, and distance from the lanes to the curbs). For example, a road may be divided into { A, B and C } sections or segments to represent three road segments. The three lanes of road segment A may be listed as { A1, A2, and A3 }. The reference route is generated by generating reference points along the reference route. For example, for a lane, the routing module 307 may connect the midpoints of two opposing curbs or edges of the lane provided by the map data. Based on machine-learned data representing collected data points at which the vehicle was driving on the lane at different points in time and the midpoint, the routing module 307 may calculate the reference point by selecting a subset of the collected data points within a predetermined proximity of the lane and applying a smoothing function to the midpoint based on the subset of collected data points.

Based on the reference point or the lane reference point, the routing module 307 may generate a reference line by interpolating the reference point such that the generated reference line is used as a reference line for controlling the ADV on the lane. In some implementations, a table of reference points and road segments representing a reference line may be downloaded to the ADV in real-time, such that the ADV may generate the reference line based on the geographical location and driving direction of the ADV. For example, in one embodiment, the ADV may generate the reference line by requesting routing services for the path segment using a path segment identifier representing the upcoming road segment ahead and/or an ADV-based GPS location. Based on the path segment identifier, the routing service may return to an ADV reference point table that contains reference points for all lanes of the road segment of interest. The ADV may consult a reference point of the lane of the path segment to generate a reference line for controlling the ADV on the lane.

As described above, the route or routing module 307 manages any data related to the user's itinerary or route. The user of the ADV specifies a start location and a destination location to obtain the trip related data. The trip-related data comprises route segments and reference lines or points of reference for the route segments. For example, based on the route map information 311, the route module 307 generates a route or link table and a reference point table. The reference points relate to road segments and/or lanes in the road segment table. The reference points may be interpolated to form one or more reference lines for controlling the ADV. The reference point may be limited to only the road segment and/or a particular lane of the road segment.

For example, the road segment table may be name-value pairs to include previous and next lanes of the road segments a-D. For example, for road segments a-D with lane 1, the road segment table may be: { (A1, B1), (B1, C1), (C1, D1) }. The reference point table may include reference points in the form of x-y coordinates for road segment lanes, such as { (a1, (x1, y1)), (B1, (x2, y2)), (C1, (x3, y3)), (D1, (x4, y4)) }, where a1 to D1 represent lane 1 of road segments a to D, and (x1, y1) to (x4, y4) are corresponding real world coordinates. In one embodiment, the road segments and/or lanes are divided into road segments/lanes of a predetermined length, such as approximately 200 meters. In another embodiment, road segments and/or lanes are divided into variable length segments/lanes according to road conditions such as the curvature of the road. In some embodiments, each road segment and/or lane may include several reference points. In some embodiments, the reference point may be transformed into another coordinate system, for example, latitude-longitude.

In some embodiments, the reference point may be transformed into a relative coordinate system, such as a base-side Shift (SL) coordinate. The base-side shift coordinate system is a coordinate system that follows a reference line with reference to a fixed reference point. For example, the (S, L) ═ 1, 0) coordinate may represent 1 meter before a base point (i.e., reference point) on a reference line with a lateral offset of 0 meters. The (S, L) — (2, 1) reference point may represent 2 meters ahead of the fixed reference point along the reference line and offset laterally by 1 meter from the reference line, e.g., by 1 meter to the left.

In one embodiment, the decision module 304 generates a coarse path profile based on reference lines provided by the routing module 307 and based on ADV-perceived obstacles around the ADV. The coarse path profile may be part of path/speed profile 313, which may be stored in persistent storage 352. A coarse path profile is generated by selecting points from the reference lines. For each point, the decision module 304 moves the point to the left or right of the reference line (e.g., candidate movement) based on one or more obstacle decisions on how to encounter the object, with the remaining points remaining stable. The candidate movement is iteratively performed using dynamic programming on the path candidates, wherein the path candidate with the smallest path cost is found using a cost function that is part of the cost function 315 of FIG. 3A, generating a coarse path profile. Examples of cost functions include costs based on: the curvature of the route path, the distance from the ADV to the perceived obstacle, and the distance from the ADV to the reference line. In one embodiment, the generated coarse route profile includes a base-side shift map that may be stored in persistent storage 352 as part of SL map/ST graphic 314.

In one embodiment, decision module 304 generates a coarse speed profile (as part of path/speed profile 313) based on the generated coarse path profile. The coarse velocity profile indicates the optimal velocity for controlling the ADV at a particular point in time. Similar to the coarse path profile, dynamic programming is used to iterate candidate velocities at different points in time, where velocity candidates (e.g., acceleration or deceleration) with minimum velocity costs are found based on a cost function (as part of cost function 315 of fig. 3A) according to the obstacles perceived by the ADV. The coarse speed profile determines whether the ADV should exceed or avoid the obstacle and steer to the left or right of the obstacle. In one embodiment, the coarse speed profile includes a base-time (ST) graphic (as part of SL map/ST graphic 314). The base-time graph shows distance traveled versus time.

In one embodiment, the planning module 305 recalculates the coarse path profile based on obstacle decisions and/or human obstacles to prohibit the planning module 305 from searching the geometric space of the obstacle. For example, if the coarse velocity profile determines that an obstacle is being swept from the left, the planning module 305 may place an obstacle (in the form of an obstacle) to the right of the obstacle to prevent calculation of an ADV sweeping the obstacle from the right. In one embodiment, the coarse path profile is recalculated by optimizing the path cost function (as part of the cost function 315) using Quadratic Programming (QP). In one embodiment, the recalculated coarse route profile includes a base-side shift map (as part of SL map/ST graphic 314).

In one embodiment, planning module 305 recalculates the coarse speed profile using Quadratic Planning (QP) to optimize the speed cost function (as part of cost function 315). Similar speed barrier constraints may be added to prohibit the QP solver from searching for some prohibited speeds. In one embodiment, the recalculated coarse velocity profile includes a base-point-time map (as part of SL map/ST graphic 314).

It should be noted that some or all of the components as shown and described above may be implemented in software, hardware, or a combination thereof. For example, such components may be implemented as software installed and stored in a persistent storage device, which may be loaded into and executed by a processor (not shown) in memory to implement the processes or operations described throughout this application. Alternatively, such components may be implemented as executable code programmed or embedded into dedicated hardware, such as an integrated circuit (e.g., an application specific integrated circuit or ASIC), a Digital Signal Processor (DSP) or Field Programmable Gate Array (FPGA), which is accessible via a respective driver and/or operating system from an application. Further, such components may be implemented as specific hardware logic within a processor or processor core as part of an instruction set accessible by software components through one or more specific instructions.

FIG. 4 is a block diagram illustrating an example of a decision and planning process in accordance with one embodiment. FIG. 5A is a block diagram illustrating an example of a decision module according to one embodiment. FIG. 5B is a block diagram illustrating an example of a planning module, according to one embodiment. Referring to fig. 4, the decision and planning process 400 includes a routing module 307, positioning/awareness data 401, a path decision process 403, a speed decision process 405, a path planning process 407, a speed planning process 409, an aggregator 411, and a trajectory calculator 413.

The path decision process 403 and the speed decision process 405 may be performed by the path decision module 501 and the speed decision module 503, respectively, of the decision module 304 in fig. 5A. Referring to fig. 4 and 5A, the route decision process 403 or route decision module 501 includes a route state machine 505, route traffic rules 507, and a base-side shift map generator 509. The path decision process 403 or the path decision module 501 may use dynamic planning to generate a coarse path profile as an initial constraint for the path planning process 407 and the speed planning process 409. In one embodiment, path state machine 505 includes at least three states: cruise status, lane change status, and idle status. The path state machine 505 provides previous planning results and important information such as whether the ADV is cruising or lane changing. The route traffic rules 507, which are part of the driving/traffic rules 312 of FIG. 3A, include traffic rules that can affect the results of the route decision module. For example, the route traffic rules 507 may include traffic information such as construction traffic signs, ADV, which may thereby avoid lanes having such construction signs. With status, traffic rules, reference lines provided by the routing module 307, and obstacles perceived by the ADV, the route decision process 403 may decide how to handle the perceived obstacles (i.e., ignore, exceed, yield, stop, pass) as part of a coarse route profile.

For example, in one embodiment, the coarse path profile is generated by a cost function that includes: cost based on curvature of the path; and a cost based on the distance from the reference line and/or the reference point to the obstacle. A point on the reference line is selected and moved to the left or right of the reference line as a candidate movement representing a path candidate. Each candidate movement has an associated cost. The associated costs of candidate moves of one or more points on the reference line can be solved sequentially (one point at a time) using dynamic programming to obtain the optimal cost. In one embodiment, SL map generator 509 generates a base-side shift map as part of a coarse path profile. The base-side shift map is a two-dimensional geometric map (similar to an x-y coordinate plane) that includes obstacle information perceived by the ADV. From the SL map, the routing decision process 403 may route an ADV route that follows the obstacle decision. Dynamic programming (or dynamic optimization) is a mathematical optimization method that decomposes the problem to be solved into a series of cost functions, solving only one of these cost functions at a time and storing its answer. The next time the same cost function occurs, only the previously computed answer needs to be looked up instead of recomputing the answer, saving computation time.

The speed decision process 405 or speed decision module 503 includes a speed state machine 511, a speed traffic rule 513, and a basepoint-time map generator 515. The speed decision process 405 or the speed decision module 503 may use dynamic programming to generate a coarse speed profile as an initial constraint for the path planning process 407 and the speed planning process 409. In one embodiment, the speed state machine 511 includes at least two states: acceleration or deceleration. The speed traffic rules 513, which are part of the driving/traffic rules 312 of fig. 3A, include traffic rules that can affect the results of the speed decision module. For example, the speed traffic rules 513 may include traffic information such as a red/green traffic light, another vehicle in an intersection route, and so on. Speed decision process 405 may generate a coarse speed profile to control when the ADV accelerates and/or decelerates through the state of the speed state machine, speed traffic rules, coarse path profile/SL map generated by decision process 403, and perceived obstacles. The base point-time map generator 515 may generate the base point-time map as part of a coarse velocity profile.

Referring to fig. 4 and 5B, path planning process 407 or path planning module 521 includes a radix-side shift map 525, a geometry smoother 527, and a path cost module 529. The base-side shift map 525 may include the base-side shift map generated by the SL map generator 509 of the route decision process 403. The path planning process 407 or the path planning module 521 may use a coarse path profile (e.g., a radix-side-shift map) as an initial constraint to recalculate the optimal reference line using quadratic planning. Quadratic programming involves minimizing or maximizing an objective function (e.g., a quadratic function with several variables) under the constraints of boundaries, linear equality, and inequality constraints. One difference between dynamic planning and quadratic planning is that quadratic planning optimizes all candidate moves for all points on the reference line at once. The geometry smoother 527 may apply a smoothing algorithm (such as B-spline or regression) to the output base-point-side shift map. The path cost module 529 may recalculate the reference line using the path cost function (as part of the cost function 315 of fig. 3A) to optimize the total cost of the candidate movement of the reference point, for example, using QP optimization performed by the QP module 540. For example, in one embodiment, the total path cost function may be:

where the path cost is summed over all points on a reference line, the heading represents the difference in radial angle (e.g., direction) between the points relative to the reference line, the curvature represents the difference between the curvature of the curve formed by the points relative to the reference line for that point, and the distance represents the lateral (perpendicular to the reference line) distance from the point to the reference line. In some embodiments, distance is the distance from the point to the destination location or an intermediate point of the reference line. In another embodiment, the curve cost is the change between the curvature values of the curves formed at adjacent points. It should be noted that a point on the reference line may be selected as a point having an equal distance to an adjacent point. Based on the path cost, the path cost module 529 may recalculate the reference lines by minimizing the path cost using quadratic programming optimization (e.g., by the QP module 540).

The speed planning process 409 or speed planning module 523 includes a base point-time map 531, a timing smoother 533, and a speed cost module 535. The base point-time graph 531 may include a base point-time (ST) graph generated by the ST graph generator 515 of the speed decision process 405. The speed planning process 409 or the speed planning module 523 may use the coarse speed profile (e.g., the radix point-time map) and the results of the path planning process 407 as initial constraints to calculate an optimal radix point-time curve. The timing smoother 533 may apply a smoothing algorithm (such as B-spline or regression) to the time series of points. The velocity cost module 535 may recalculate the ST graph using the velocity cost function (as part of the cost function 315 of fig. 3A) to optimize the total cost of the motion candidates (e.g., acceleration/deceleration) at different points in time. For example, in one embodiment, the total speed cost function may be:

where the velocity cost is summed over all time series points, speed' represents the acceleration value or the cost of changing the velocity between two adjacent points, speed "represents the jerk value, or the derivative of the acceleration value, or the cost of changing the velocity change between two adjacent points, and distance represents the distance of the ST point to the destination location. Here, the speed cost module 535 computes the basepoint-time map by minimizing the speed cost using quadratic programming optimization (e.g., by the QP module 540).

The aggregator 411 performs a function of aggregating the path planning result and the speed planning result. For example, in one embodiment, the aggregator 411 may combine a two-dimensional ST graphic and a SL map into a three-dimensional SLT graphic. In another embodiment, the aggregator 411 may interpolate (or fill with additional points) based on 2 consecutive points on the SL reference line or ST curve. In another embodiment, the aggregator 411 may convert the reference point from (S, L) coordinates to (x, y) coordinates. The trajectory generator 413 may calculate a final trajectory for controlling the ADV. For example, based on the SLT graph provided by the aggregator 411, the trajectory generator 413 computes a list of (x, y, T) points that indicate when the ADV should pass a particular (x, y) coordinate.

Thus, referring back to fig. 4, the path decision process 403 and the speed decision process 405 will generate a coarse path profile and a coarse speed profile taking into account obstacles and/or traffic conditions. Based on all path decisions and speed decisions related to the obstacle, the path planning process 407 and speed planning process 409 will optimize the coarse path profile and coarse speed profile using QP planning according to the obstacle to generate the best trajectory with the smallest path cost and/or speed cost. In another embodiment, the path cost and the speed cost may be calculated by the path cost module 1110 and the speed cost module 1120 of fig. 12A-12B, described further below.

FIG. 6 is a block diagram illustrating a base-side shift diagram according to one embodiment. Referring to fig. 6, the map 600 has an S horizontal axis (or base point) and an L vertical axis (or side shift). As described above, the base-side shift coordinate is a relative geometric coordinate system that is referenced to a specific base point on the reference line and follows the reference line. For example, the (S, L) ═ 1, 0) coordinate may represent 1 meter before the base point (i.e., the reference point) on the reference line and have a lateral offset of 0 meters. The (S, L) — (2, 1) reference point may represent 2 meters ahead of the fixed reference point along the reference line and offset vertically laterally from the reference line by 1 meter, e.g., left offset.

Referring to fig. 6, a map 600 includes a reference line 601 and obstacles 603 to 609 perceived by an ADV. In one embodiment, the obstacles 603-609 may be perceived by the RADAR or LIDAR unit of the ADV in different coordinate systems and may be translated to the SL coordinate system. In another embodiment, the obstacles 603-609 may be artificially created obstacles as constraints, such that the decision module and planning module do not search in constrained geometric space. In this example, a route decision module, such as route decision module 501, may generate a decision for each of obstacles 603-609, such as a decision to avoid obstacles 603-608 and to sweep (closely approach) obstacle 609 (i.e., these obstacles may be other cars, buildings, and/or structures). A path planning module, such as path planning module 521, may then recalculate or optimize the reference line 601 using QP planning based on the path costs in view of the obstacles 603-609 to optimize the reference line 601 with the smallest overall cost as described above. In this example, ADV 101 sweeps over (or approaches very closely to) obstacle 609 from the left side of obstacle 609.

Fig. 7A and 7B are block diagrams illustrating a base point-time diagram according to some embodiments. Referring to fig. 7A, a graph 700 has a base (or S) vertical axis and a time (or T) horizontal axis. The graph 700 includes a curve 701 and obstacles 703 to 707. As described above, the curve 701 on the base-point-time graph indicates time and the distance of the ADV from the base point. For example, (T, S) ═ 10000, 150) can represent 10000 milliseconds, and the ADV will be 150 meters from the base point (i.e., the reference point). In this example, the obstacle 703 may be a building/structure to be avoided, and the obstacle 707 may be a human obstacle corresponding to a decision to pass the moving vehicle.

Referring to fig. 7B, in this case, an artifact 705 is added to the ST graph 710 as a constraint. The human obstruction may be, for example, a red light or a pedestrian in the path at a distance of approximately S2 from the cardinal point of reference as perceived by the ADV. Obstacle 705 corresponds to a decision to "stop" the ADV until the man-made obstacle is later cleared (i.e., the traffic light changes from red to green, or the pedestrian is no longer in the path).

FIG. 8 is a flow chart illustrating a method according to one embodiment. Process 800 may be performed by processing logic that may comprise software, hardware, or a combination thereof. For example, the process 800 may be performed by the perception and planning system 110 of an autonomous vehicle. Referring to FIG. 8, at block 801, processing logic calculates a first trajectory based on map and route information. At block 802, processing logic generates a path profile based on the first trajectory, the traffic rules, and obstacle information describing one or more obstacles perceived by the ADV. At block 803, processing logic generates a speed profile based on the path profile, where for each obstacle, the speed profile includes a decision to make or exceed the obstacle. At block 804, processing logic performs quadratic programming optimization on the path profile and the speed profile to identify the best path with the best speed. Quadratic programming optimization may be performed using respective path cost functions, speed cost functions, and/or obstacle cost functions to determine an optimal route having a minimum total cost. At block 805, processing logic generates a second trajectory based on the optimal path and the optimal speed, thereby autonomously controlling the ADV according to the second trajectory.

In one embodiment, the path profile and the velocity profile are iteratively generated using dynamic programming. In one embodiment, for each obstacle decision encountered, the path profile includes decisions to avoid, yield, ignore, or skim from the left or right of the encountered obstacle.

In one embodiment, performing quadratic programming optimization on the path profile and the speed profile comprises: optimizing a first cost function (e.g., one or more path cost functions) using quadratic programming to generate a base-point-side shift map based on a path profile; and optimizing a second cost function (e.g., one or more speed cost functions) using quadratic programming to generate a basepoint-time map based on the speed profile. In another embodiment, the cardinal-lateral shift map is generated by forming one or more obstacles based on one or more obstacle decisions. In another embodiment, the first cost function includes a heading cost, a curvature cost, and/or a distance cost. In another embodiment, the second cost function includes an acceleration cost, a jerk cost, and/or a distance cost. In another embodiment, the processing logic further inserts a plurality of points to the second track that are not present in the first track based on the base-point-side shift map and the base-point-time map.

FIG. 9 is a block diagram illustrating an example of a planning module, according to one embodiment. Planning module 901 is similar to planning module 305 of FIG. 5B. In addition, the planning module 901 includes a gradient descent module 903. The gradient descent module 903 may perform a gradient descent optimization method to optimize the cost function. For example, in one embodiment, the gradient descent module 903 performs a gradient descent optimization on a path cost function similar to the path cost function described above, instead of a quadratic programming optimization performed by the path cost module 529. In another embodiment, the gradient descent module 903 performs a gradient descent optimization on a velocity cost function similar to the velocity cost function described above, instead of a quadratic programming optimization performed by the velocity cost module 535. Gradient descent is a first order iterative optimization algorithm used to find the minimum of a function. To find the local minimum of the function using gradient descent, the algorithm takes a step size proportional to the negative value of the gradient of the function at the current point. The algorithm may compute the derivative (i.e., gradient) of the cost function at the current value and take a step size proportional to the derivative and repeat until the minimum point is reached.

FIG. 10 is a flow chart illustrating a method according to one embodiment. Process 1000 may be performed by processing logic that may comprise software, hardware, or a combination thereof. For example, the process 1000 may be performed by the perception and planning system 110 of an autonomous vehicle. Referring to fig. 10, at block 1001, processing logic calculates a first trajectory based on map and route information. At block 1002, processing logic generates a path profile based on the first trajectory, traffic rules, and obstacle information describing one or more obstacles perceived by the ADV, wherein for each obstacle, the path profile includes a decision to sweep or let go from the left or right side of the obstacle. At block 1003, processing logic generates a speed profile from the traffic rules based on the path profile. At block 1004, processing logic performs a gradient descent optimization based on the path profile and the velocity profile to generate a second trajectory that represents the optimized first trajectory. The gradient descent optimization may be performed using respective path cost functions, speed cost functions, and/or obstacle cost functions to determine an optimal route having a minimum total cost. At block 1005, processing logic controls the ADV according to the second trajectory.

In one embodiment, the path profile and the speed profile are generated iteratively using dynamic programming. In one embodiment, for each obstacle encountered in the obstacle information, the speed profile includes a decision to follow, exceed, yield, stop, or pass the encountered obstacle.

In one embodiment, performing gradient descent optimization based on the path profile and the velocity profile comprises: optimizing the first cost function and the second cost function using gradient descent optimization to generate a base point-side shift map and a base point-time map based on the path profile and the speed profile, respectively; and generating a second trajectory based on the base point-side shift map and the base point-time map, thereby controlling the ADV according to the second trajectory. In another embodiment, the cardinal-lateral shift map is generated by forming one or more obstacles based on one or more obstacle decisions. In another embodiment, the first cost function and the second cost function include a heading cost, a curvature cost, a distance cost, an acceleration cost, and a jerk cost. In another embodiment, the processing logic further inserts a plurality of points in the second track that are not present in the first track based on the base-point-side shift map and the base-point-time map.

In one embodiment, the planning module may determine all feasible and/or possible decisions to move the ADV from the starting location to the ending location based on the obstacles encountered by the ADV. Without initial constraints, the planning module 1100 optimizes each feasible trajectory according to feasible and/or possible obstacle decisions (i.e., avoid, exceed, pass, yield, sweep, stop, ignore) based on the reference lines provided by the routing module 307 and calculates a minimum total cost for each feasible trajectory. For example, for a red traffic light obstacle in a lane, a likely decision would be to stop the ADV, although other obstacle decisions are also possible. The planning module 1100 then selects the trajectory with the smallest total cost to control the ADV. FIG. 11 is a block diagram illustrating an example of a planning module, according to one embodiment. Fig. 12A and 12B are block diagrams illustrating a path cost module and a speed cost module, respectively, according to one embodiment.

Referring to fig. 11, planning module 1100 is similar to planning module 305 of fig. 5B. The planning module 1100 includes an obstacle planning module 1101, a path cost module 1110, and a speed cost module 1120. The obstacle planning module 1101 includes an obstacle cost calculator 1103. The obstacle planning module 1101 plans how to control ADV according to obstacles. The obstacle cost calculator 1103 may calculate an obstacle cost for each obstacle perceived by the ADV. The obstacle cost may represent a cost of avoiding a conflict between the obstacle and the particular trajectory that is calculated. For example, the cost of avoiding a collision between an obstacle and a trajectory may include a cost based on the distance between the obstacle and the closest point of the trajectory ("distance cost"), and a cost of estimating the speed of passage past the obstacle ("cost of speed of passage").

In one embodiment, the distance cost may be ignored when the distance between the trajectory and the obstacle is greater than a threshold (such as 2 meters). In one embodiment, the distance cost is an exponential function. For example, the distance cost may be: w is a₁*exp^(2-x)-1, wherein w₁Is a weight factor and x is the distance between the trajectory and the obstacle. In one embodiment, the cost of passing the speed is a logarithmic function. For example, the cost of passing speed may be: w is a₂Log (speed,4), wherein w₂Is the weighting factor and speed is the relative speed of the ADV with respect to the passing obstacle. In one embodiment, the total obstacle cost is calculated based on the distance cost and the cost of the passing speed, e.g., the total obstacle cost is the product of the two costs: (w)₁*exp^(2-x)-1)*(w₂*log(speed,4))。

The path cost module 1110 is similar to the path cost module 529 of fig. 5B. Referring to fig. 12A, the path cost module 1110 includes a curvature cost calculator 1201, a curvature delta cost calculator 1203, and a forward length cost calculator 1205. The curvature cost calculator 1201 calculates a curvature cost based on the curvature of each point along the trajectory. In one embodiment, the curvature cost is an exponential function. For example, the curvature cost may be w₃*exp(100 x c) -1, wherein w₃Is a weighting factor, and c is typically at [0, 0.2 ]]Curvature within a range. The curvature incremental cost calculator 1203 may calculate a curvature incremental cost based on a difference in curvature between two adjacent points of the calculated trajectory. In one embodiment, the curvature increment cost is an exponential function. For example, the incremental cost of curvature may be w₄Exp (100 × c') -1, wherein w₄Is the weight factor and c' is the change in curvature. The forward length cost calculator 1205 may calculate a forward length cost representing a cost of moving forward toward the reference line of the trajectory. In one embodiment, the forward length cost is a linear function. For example, the forward length cost may be w₅(X-X), wherein, w₅Is a weight factor, X is the distance to the destination of the path segment, and X is the distance traveled. In one embodiment, the path cost module 1110 may calculate the total path cost based on the curvature cost, the curvature delta cost, and/or the forward length cost for each of all points along the calculated trajectory. For example, the total path cost may be the sum of these three costs for each of all points along the computed trajectory. The path cost may be optimized by quadratic programming and/or gradient descent optimization as described above to obtain a minimum path cost.

Speed cost module 1120 is similar to speed cost module 535 of FIG. 5B. Referring to fig. 12B, the speed cost module 1120 includes a speed cost calculator 1207, a speed incremental cost calculator 1209, and a speed incremental change cost calculator 1211. The speed cost calculator 1207 may calculate individual speed costs based on speed according to the speed limit at each point. For example, in one embodiment, the cost function may be the absolute value of the current road speed limit minus the ADV operating speed. The velocity delta cost calculator 1209 may calculate the cost of changing the velocity between two adjacent points. The velocity delta change cost calculator 1211 may calculate a cost of changing the acceleration between two adjacent points of the trajectory. In one embodiment, the speed increment cost and the speed increment change cost are linear functions.

In another embodiment, the speed increment cost and the speed increment change cost are constant when the speed increment and the speed increment change are below or above a predetermined threshold, respectively. In one embodiment, the speed cost module 1120 then calculates a total speed cost based on the speed cost, the speed increment cost, and/or the speed increment cost for each of all points along the calculated trajectory. For example, the total velocity cost may be the sum of these three costs for each point along all points of the calculated base point-time curve. The total speed cost may be optimized by quadratic programming and/or gradient descent optimization as described above, resulting in a minimum speed cost. The ADV may then be autonomously controlled by the planning module 1100 by selecting the trajectory with the overall least path cost and velocity cost.

FIG. 13 is a flow chart illustrating a method according to one embodiment. Process 1300 may be performed by processing logic that may comprise software, hardware, or a combination thereof. For example, the process 1300 may be performed by the perception and planning system 110 of an autonomous vehicle. Referring to fig. 13, at block 1301, processing logic generates a number of possible decisions for tracking an ADV from a first location to a second location according to a set of traffic rules based on perception information that perceives a driving environment (including one or more obstacles) around the ADV. At block 1302, processing logic calculates a plurality of trajectories based on a combination of one or more feasible decisions. At block 1303, processing logic calculates a total cost for each trace using a plurality of cost functions. At block 1304, processing logic selects the one trajectory with the smallest total cost as the driving trajectory for autonomously controlling the ADV.

FIG. 14A is a flow diagram illustrating a process of calculating a path cost according to one embodiment. Process 1400 may be performed as part of block 1303 of fig. 13. Process 1400 may be performed by processing logic that may comprise software, hardware, or a combination thereof. For example, the process 1400 may be performed by the route cost for autonomous vehicle module 1110. Referring to fig. 14A, at block 1401, processing logic calculates a curvature cost based on the curvature of each point along the trajectory. At block 1402, processing logic calculates a curvature delta cost based on a difference in curvature between two neighboring points. At block 1403, processing logic calculates a forward length cost representing the cost of moving forward toward the reference line of the trace. At block 1404, processing logic calculates a total path cost based on the curvature cost, the curvature delta cost, and the forward length cost.

FIG. 14B is a flow chart illustrating a process of calculating a speed cost according to one embodiment. Process 1410 may be performed as part of block 1303 of fig. 13. Process 1410 may be performed by processing logic that may include software, hardware, or a combination thereof. For example, process 1410 may be performed by autonomous vehicle speed cost module 1120. Referring to FIG. 14B, at block 1411, processing logic calculates a speed cost based on the speed according to the speed limit at each point. At block 1412, processing logic calculates a speed increment cost representing the cost of changing speed between two adjacent points. At block 1413, processing logic calculates a speed delta change cost representing a cost to change the speed change between two adjacent points. At block 1414, processing logic calculates a total speed cost based on the speed cost, the speed delta cost, and the speed delta change cost.

In one embodiment, for each track, the processing logic further calculates a path cost using a path cost function representing a cost of tracking the ADV from the first location to the second location according to the track. The processing logic also calculates a velocity cost function representing a cost of controlling the ADV at different velocities along the trajectory, wherein the total cost is calculated based on the path cost and the velocity cost.

In one embodiment, calculating the path cost using the path cost function comprises: calculating a curvature cost based on the curvature of each point along the trajectory; and calculating a curvature delta cost based on a difference in curvature between two adjacent points, wherein the path cost is calculated based on the curvature cost and the curvature delta cost for all points along the trajectory. In another embodiment, the processing logic further calculates a forward length cost representing a cost of moving forward towards the reference line of the trajectory, wherein the path cost is further calculated based on the forward length cost for each point.

In one embodiment, calculating the speed cost using the speed cost function includes: calculating an individual speed cost based on the speed from the speed limit at each point, and calculating a speed increment cost representing a cost of changing the speed between two adjacent points, wherein the speed cost is calculated based on the individual speed cost and the speed increment cost for all points along the trajectory. In another embodiment, the processing logic further calculates an acceleration cost based on the acceleration of each point of the trajectory, wherein the velocity cost is further calculated based on the acceleration cost of each point.

In one embodiment, the processing logic is further to calculate a perceived obstacle cost for each obstacle, the obstacle cost representing a cost of avoiding a conflict between the trajectory and the obstacle, wherein the total cost is further calculated based on the obstacle cost. In another embodiment, calculating the obstacle cost includes calculating a minimum distance between the trajectory and the obstacle, and calculating a passing speed of the estimated passing obstacle, wherein the obstacle cost is calculated based on the minimum distance and the passing speed.

FIG. 15 is a block diagram illustrating an example of a data processing system that may be used with one embodiment of the present disclosure. For example, system 1500 may represent any of the data processing systems described above that perform any of the processes or methods described above, such as, for example, any of sensing and planning systems 110 or servers 103-104 of fig. 1. System 1500 may include many different components. These components may be implemented as Integrated Circuits (ICs), portions of integrated circuits, discrete electronic devices or other modules adapted for a circuit board, such as a motherboard or add-in card of a computer system, or as components otherwise incorporated within a chassis of a computer system.

It should also be noted that system 1500 is intended to illustrate a high-level view of many components of a computer system. However, it is to be understood that some embodiments may have additional components and, further, other embodiments may have different arrangements of the components shown. System 1500 may represent a desktop computer, a laptop computer, a tablet computer, a server, a mobile phone, a media player, a Personal Digital Assistant (PDA), a smart watch, a personal communicator, a gaming device, a network router or hub, a wireless Access Point (AP) or repeater, a set-top box, or a combination thereof. Further, while only a single machine or system is illustrated, the term "machine" or "system" shall also be taken to include any collection of machines or systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

In one embodiment, the system 1500 includes a processor 1501, memory 1503, and devices 1505-1508 connected by a bus or interconnect 1510. Processor 1501 may represent a single processor or multiple processors including a single processor core or multiple processor cores. Processor 1501 may represent one or more general-purpose processors, such as a microprocessor, Central Processing Unit (CPU), or the like. More specifically, processor 1501 may be a Complex Instruction Set Computing (CISC) microprocessor, Reduced Instruction Set Computing (RISC) microprocessor, Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processor 1501 may also be one or more special-purpose processors, such as an Application Specific Integrated Circuit (ASIC), a cellular or baseband processor, a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), a network processor, a graphics processor, a communications processor, a cryptographic processor, a coprocessor, an embedded processor, or any other type of logic capable of processing instructions.

Processor 1501 (which may be a low-power multi-core processor socket such as an ultra-low voltage processor) may serve as a main processing unit and central hub for communicating with the various components of the system. Such a processor may be implemented as a system on a chip (SoC). Processor 1501 is configured to execute instructions for performing the operations and steps discussed herein. The system 1500 may also include a graphics interface to communicate with an optional graphics subsystem 1504, which may include a display controller, a graphics processor, and/or a display device.

Processor 1501 may be in communication with memory 1503, which in one embodiment may be implemented via multiple memory devices to provide a given amount of system storage. The memory 1503 may include one or more volatile storage (or memory) devices such as Random Access Memory (RAM), dynamic RAM (dram), synchronous dram (sdram), static RAM (sram), or other types of storage devices. Memory 1503 may store information including sequences of instructions that are executed by processor 1501, or any other device. For example, executable code and/or data for various operating systems, device drivers, firmware (e.g., an input output basic system or BIOS), and/or applications may be loaded into memory 1503 and executed by processor 1501. The operating system may be any type of operating system, for example, a Robotic Operating System (ROS), from

Of a company

Operating System, Mac from apple Inc

From

Of a company

LINUX, UNIX, or other real-time or embedded operating systems.

System 1500 may also include IO devices such as devices 1505 through 1508 including network interface device 1505, optional input device 1506, and other optional IO devices 1507. Network interface device 1505 may include a wireless transceiver and/or a Network Interface Card (NIC). The wireless transceiver may be a WiFi transceiver, an infrared transceiver, a bluetooth transceiver, a WiMax transceiver, a wireless cellular telephone transceiver, a satellite transceiver (e.g., a Global Positioning System (GPS) transceiver), or other Radio Frequency (RF) transceiver, or a combination thereof. The NIC may be an ethernet card.

The input device 1506 may include a mouse, a touch pad, a touch-sensitive screen (which may be integrated with the display device 1504), a pointing device (such as a stylus) and/or a keyboard (e.g., a physical keyboard or a virtual keyboard displayed as part of the touch-sensitive screen). For example, the input device 1506 may include a touch screen controller coupled to a touch screen. Touch screens and touch screen controllers, for example, may detect contact and movement or discontinuities thereof using any of a variety of touch sensitive technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch screen.

IO device 1507 may include an audio device. The audio device may include a speaker and/or microphone to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and/or telephony functions. Other IO devices 1507 may also include Universal Serial Bus (USB) ports, parallel ports, serial ports, printers, network interfaces, bus bridges (e.g., PCI-PCI bridges), sensors (e.g., such as accelerometer motion sensors, gyroscopes, magnetometers, light sensors, compasses, proximity sensors, etc.), or combinations thereof. The device 1507 may also include an imaging processing subsystem (e.g., a camera) that may include an optical sensor, such as a Charge Coupled Device (CCD) or Complementary Metal Oxide Semiconductor (CMOS) optical sensor, for facilitating camera functions, such as recording photographs and video clips. Certain sensors can be coupled to interconnect 1510 via a sensor hub (not shown), while other devices, such as a keyboard or thermal sensors, can be controlled by an embedded controller (not shown) depending on the particular configuration or design of system 1500.

To provide persistent storage for information such as data, applications, one or more operating systems, etc., a mass storage device (not shown) may also be coupled to processor 1501. In various embodiments, such mass storage devices may be implemented via Solid State Devices (SSDs) in order to achieve thinner and lighter system designs and improve system responsiveness. However, in other embodiments, the mass storage device may be implemented primarily using a Hard Disk Drive (HDD), with a smaller amount of the SSD storage device acting as an SSD cache to enable non-volatile storage of context state and other such information during a power down event, enabling fast power up upon a system activity restart. Additionally, a flash device may be coupled to processor 1501, for example, via a Serial Peripheral Interface (SPI). Such flash memory devices may provide non-volatile storage of system software, including the BIOS and other firmware of the system.

Storage 1508 may include a computer-accessible storage medium 1509 (also referred to as a machine-readable storage medium or a computer-readable medium) on which is stored one or more sets of instructions or software (e.g., modules, units, and/or logic 1528) embodying any one or more of the methodologies or functions described herein. The processing module/unit/logic 1528 may represent any of the above components, such as the decision module 304, the planning module 305, the control module 306, the path decision module 501, the speed decision module 502 of fig. 5A, and the path planning module 521, the speed planning module 523 of fig. 5B of fig. 3A and 3B. Processing module/unit/logic 1528 may also reside, completely or at least partially, within memory 1503 and/or within processor 1501 during execution thereof by data processing system 1500, memory 1503 and processor 1501, data processing system 1500, memory 1503 and processor 1501 also constituting machine-accessible storage media. Processing module/unit/logic 1528 may also transmit or receive over a network via network interface device 1505.

The computer-readable storage medium 1509 may also be used to permanently store some of the software functions described above. While the computer-readable storage medium 1509 is shown in an exemplary embodiment to be a single medium, the term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media, or any other non-transitory machine-readable medium.

The processing module/unit/logic 1528, components, and other features described herein may be implemented as discrete hardware components or integrated within the functionality of hardware components, such as ASICS, FPGAs, DSPs, or similar devices. Further, the processing module/unit/logic 1528 may be implemented as firmware or functional circuitry within a hardware device. Further, the processing module/unit/logic 1528 may be implemented in any combination of hardware devices and software components.

It should be noted that while system 1500 is illustrated with various components of a data processing system, it is not intended to represent any particular architecture or manner of interconnecting the components; as such details are not germane to embodiments of the present disclosure. It will also be appreciated that network computers, hand-held computers, mobile telephones, servers, and/or other data processing systems which have fewer components or perhaps more components may also be used with embodiments of the present disclosure.

Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, considered to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as those set forth in the appended claims, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Embodiments of the present disclosure also relate to apparatuses for performing the operations herein. Such a computer program is stored in a non-transitory computer readable medium. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium (e.g., read only memory ("ROM"), random access memory ("RAM"), magnetic disk storage media, optical storage media, flash memory devices).

The processes or methods depicted in the foregoing figures may be performed by processing logic that comprises hardware (e.g., circuitry, dedicated logic, etc.), software (e.g., embodied on a non-transitory computer readable medium), or a combination of both. Although the processes or methods are described above in terms of some sequential operations, it should be appreciated that some of the operations may be performed in a different order. Further, some operations may be performed in parallel rather than sequentially.

Embodiments of the present disclosure are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the disclosure as described herein.

In the foregoing specification, embodiments of the invention have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. A computer-implemented method of generating a driving trajectory for an autonomous vehicle, the method comprising:

calculating a first trajectory based on the map and the route information;

generating a path profile based on the first trajectory, traffic rules, and obstacle information describing one or more obstacles perceived by the autonomous vehicle;

generating a speed profile based on the path profile, wherein the speed profile includes, for each of the plurality of obstacles, a decision to make or exceed the obstacle;

performing a quadratic programming optimization on the path profile and the speed profile to identify an optimal path having an optimal speed, wherein the performing quadratic programming optimization comprises:

optimizing a path cost function using quadratic programming to recalculate the path profile, the recalculated path profile including a base-side shift map, an

Re-computing the speed profile using quadratic programming to optimize a speed cost function, the re-computed speed profile comprising a base point-time map; and

generating a second trajectory based on the optimal path and the optimal speed to autonomously control the autonomous vehicle in accordance with the second trajectory.

2. The method of claim 1, wherein the path profile and the speed profile are iteratively generated using dynamic programming.

3. The method of claim 1, wherein the path profile includes, for each obstacle decision encountered, a decision to let go, ignore, or skim from the left or right of the encountered obstacle.

4. The method of claim 1, wherein the cardinal-lateral shift map is generated by forming one or more obstacles based on one or more obstacle decisions.

5. The method of claim 1, wherein the path cost function includes a heading cost, a curvature cost, and a distance cost.

6. The method of claim 1, wherein the velocity cost function includes an acceleration cost, a jerk cost, and a distance cost.

7. The method of claim 1, further comprising: inserting a plurality of points, which are not present in the first track, into the second track based on the base point-side shift map and the base point-time map.

8. A non-transitory machine-readable medium having instructions stored thereon, which when executed by a processor, cause the processor to perform operations comprising:

calculating a first trajectory based on the map and the route information;

generating a path profile based on the first trajectory, traffic rules, and obstacle information describing one or more obstacles perceived by an autonomous vehicle;

9. The non-transitory machine-readable medium of claim 8, wherein the path profile and the speed profile are iteratively generated using dynamic programming.

10. The non-transitory machine-readable medium of claim 8, wherein the path profile includes, for each obstacle decision encountered, a decision to let go, ignore, or skim left or right of the encountered obstacle.

11. The non-transitory machine-readable medium of claim 8, wherein the base-point-side shift map is generated by forming one or more obstacles based on one or more obstacle decisions.

12. The non-transitory machine-readable medium of claim 8, wherein the path cost function includes a heading cost, a curvature cost, and a distance cost.

13. The non-transitory machine-readable medium of claim 8, wherein the velocity cost function includes an acceleration cost, a jerk cost, and a distance cost.

14. The non-transitory machine-readable medium of claim 8, further comprising: inserting a plurality of points, which are not present in the first track, into the second track based on the base point-side shift map and the base point-time map.

15. A data processing system comprising:

a processor; and

a memory coupled to the processor to store instructions that, when executed by the processor, cause the processor to perform operations comprising:

calculating a first trajectory based on the map and the route information;

16. The system of claim 15, wherein the path profile and the speed profile are iteratively generated using dynamic programming.

17. The system of claim 15, wherein the path profile includes, for each obstacle decision encountered, a decision to let go, ignore, or skim left or right of the encountered obstacle.

18. The system of claim 15, wherein the cardinal-lateral shift map is generated by forming one or more obstacles based on one or more obstacle decisions.