Method for a vehicle, vehicle and storage medium

Abstract

Methods, vehicles, and storage media for vehicles are provided. Embodiments of a sampled maneuver implementer are provided. In embodiments, a method includes obtaining, using at least one processor, a maneuver description for a vehicle that describes a joint of dynamic station-time constraints and dynamic station-space-time constraints for the vehicle, where the dynamic station-time constraints are parameterized over time and the dynamic station-space-time constraints are parameterized over station and time; sampling, using the at least one processor, the dynamic station-time constraints and the dynamic station-space-time constraints; solving, using the at least one processor, an optimization problem using the sampled dynamic station-time constraints, the sampled dynamic station-space-time constraints, and a cost function of a motion model; and generating, using the at least one processor, a trajectory based on the solved optimization problem, where the trajectory satisfies the dynamic station-time constraints and the dynamic station-space-time constraints imposed by the maneuver description.

Description

Technical Field

[0001] The following description pertains to route planners used in autonomous vehicles. Background Technology

[0002] Autonomous vehicles utilize route planners within their software stacks to generate candidate trajectories for various scenarios. The planner uses sensor data and the vehicle's physical state (e.g., position, speed, heading) to generate possible trajectories that avoid collisions with nearby agents (e.g., other vehicles, pedestrians). When determining which candidate trajectory the vehicle should take for a given scenario, the planner typically considers traffic law violations and other possible driving rules (e.g., safety, ethics, local culture, passenger comfort, courtesy, performance, etc.). Therefore, it is desirable to evaluate the planned trajectory under a wide range of real-world scenarios. Summary of the Invention

[0003] A technology that provides sampling-based motion actuators.

[0004] In one embodiment, a method includes: obtaining a maneuvering description of a vehicle using at least one processor, the maneuvering description describing a joint dynamic station-time constraint and dynamic station-space-time constraint on the vehicle, wherein the dynamic station-time constraint is parameterized in time, and the dynamic station-space-time constraint is parameterized in both station and time; sampling the dynamic station-time constraint and the dynamic station-space-time constraint using the at least one processor; solving an optimization problem using the sampled dynamic station-time constraint, the sampled dynamic station-space-time constraint, and a cost function of a motion model using the at least one processor; and generating a trajectory based on the solved optimization problem using the at least one processor, wherein the trajectory satisfies the dynamic station-time constraint and the dynamic station-space-time constraint imposed by the maneuvering description.

[0005] In the embodiment, the dynamic station-space-time constraint explicitly includes bias decisions.

[0006] In this embodiment, the motion model is a kinematic bicycle model.

[0007] In this embodiment, the solution is continuous and iterative.

[0008] In an embodiment, the continuous and iterative solution converges when the optimized trajectory satisfies the unsampled dynamic station-time constraints and the station-space-time constraints.

[0009] In one embodiment, the trajectory maximizes the comfort constraints imposed on the vehicle.

[0010] In an embodiment, the method further includes: using the at least one processor to solve a longitudinal rate optimization problem to determine where to begin sampling the dynamic station-time constraints and the dynamic station-space-time constraints.

[0011] In this embodiment, the longitudinal rate optimization problem includes static rate distribution constraints and maneuver station-time constraints.

[0012] In one embodiment, the static rate distribution constraint limits the maximum lateral acceleration of the vehicle by taking into account path curvature.

[0013] In an embodiment, the solution to the longitudinal velocity optimization problem provides an initial guess of the acceleration and velocity for solving the optimization problem.

[0014] In one embodiment, the method further includes: using a control circuit to initiate a maneuver of the vehicle based on the trajectory.

[0015] In one embodiment, a non-transitory computer-readable storage medium stores instructions that, when executed by at least one processor, cause the at least one processor to perform the method described above.

[0016] In one embodiment, a vehicle includes: at least one processor; and a non-transitory computer-readable storage medium storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method described above.

[0017] One or more of the disclosed embodiments offer one or more of the following advantages. A sampled maneuvering actuator generates a trajectory that satisfies dynamic station-time and station-space-time constraints imposed by homotopy while simultaneously maximizing passenger comfort. The trajectory is generated by solving an optimization problem using a cost function relating the dynamic station-time and station-space-time constraints, the motion model, and the passenger comfort constraints. Bias decisions are performed under the dynamic station-space-time constraints, even if the agent exceeds the prediction range. The station-time constraints are parameterized by time, for which a corresponding time step can be continuously and iteratively optimized without any information loss, i.e., no approximation. For a suitably formulated problem, a single iteration of optimization may be sufficient to generate a trajectory that satisfies the dynamic station-time and station-space-time constraints imposed by homotopy, as well as the passenger comfort constraints.

[0018] Imposing station and spatial constraints on each other yields a fully maneuverable description that can be continuously sampled along a defined time range, which greatly simplifies the architecture of the planning system. No further decisions are required, and the proximity constraint is directly expressed as a continuous function that can be used for optimization.

[0019] These and other aspects, features, and implementations can be expressed as methods, apparatus, systems, components, program products, parts, or steps for performing the function, and other means. These and other aspects, features, and implementations will become apparent from the following description, including the claims. Attached Figure Description

[0020] Figure 1 Examples of autonomous vehicles (AVs) with autonomous capabilities according to one or more embodiments are shown.

[0021] Figure 2 An example "cloud" computing environment is shown according to one or more embodiments.

[0022] Figure 3 A computer system according to one or more embodiments is shown.

[0023] Figure 4 An example architecture of an AV is shown according to one or more embodiments.

[0024] Figure 5 It is a block diagram of a route planning system according to one or more embodiments.

[0025] Figure 6 An example parallel illustrates a driving scenario where a vehicle, according to one or more embodiments, must change lanes due to obstacles in its path.

[0026] Figure 7A and 7B Descriptions of maneuvering actions and spatial constraints according to one or more embodiments are shown respectively.

[0027] Figure 8 An example model predictive controller (MPC) class for collision avoidance maneuvers is shown according to one or more embodiments.

[0028] Figure 9 This illustrates sampling of station-time constraints according to one or more embodiments.

[0029] Figure 10 This illustrates sampling of space-station-time constraints according to one or more embodiments.

[0030] Figure 11 An example vertical implementation according to one or more embodiments is shown.

[0031] Figure 12A This is a description of example maneuvers in an example driving scenario involving two intelligent agents, based on one or more embodiments.

[0032] Figure 12B The acceleration and velocity distributions of example driving scenarios according to one or more embodiments are shown.

[0033] Figure 12C It is a bird's-eye view (BEV) of an example driving scenario according to one or more embodiments.

[0034] Figure 13 It is a flowchart of a process for sampling dynamic station-time and station-space-time constraints according to one or more embodiments. Detailed Implementation

[0035] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of the invention. However, it will be apparent that the invention may be practiced without these specific details. In other instances, well-known constructions and apparatuses are shown in block diagram form to avoid unnecessarily obscuring the invention.

[0036] In the accompanying drawings, for ease of description, a specific arrangement or order of schematic elements (such as those representing devices, modules, instruction blocks, and data elements) is shown. However, those skilled in the art will understand that the specific order or arrangement of the schematic elements in the drawings is not intended to imply a requirement for a particular processing order or sequence, or a separation of processing procedures. Furthermore, the inclusion of schematic elements in the drawings is not intended to imply that such elements are required in all embodiments, nor is it intended to imply that features represented by such elements cannot be included in some embodiments or cannot be combined with other elements in some embodiments.

[0037] Furthermore, in the accompanying drawings, connecting elements, such as solid or dashed lines or arrows, are used to illustrate connections, relationships, or associations between two or more other schematic elements. The absence of any such connecting element does not imply that connections, relationships, or associations cannot exist. In other words, connections, relationships, or associations between some elements are not shown in the drawings so as not to obscure the content of this disclosure. Additionally, for ease of illustration, a single connecting element is used to represent multiple connections, relationships, or associations between elements. For example, if a connecting element represents communication of signals, data, or instructions, those skilled in the art will understand that such an element represents one or more signal paths (e.g., a bus) that may be necessary to influence the communication.

[0038] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the various embodiments described. However, it will be apparent to those skilled in the art that the various embodiments described can be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0039] The features described below can each be used independently of each other or in any combination with other features. However, any individual feature may not solve any of the problems discussed above, or may only solve one of the problems discussed above. Some of the problems discussed above may not be fully solved by any of the features described herein. Although headings are provided, information relating to specific headings but not found in the sections bearing those headings can be found elsewhere in this specification. Embodiments are described herein based on the following summary:

[0040] 1. General Overview

[0041] 2. System Overview

[0042] 3. Autonomous Vehicle Architecture

[0043] 4. Sample-based motion actuator

[0044] General Overview

[0045] Techniques for sample-based motion actuators are provided. For example... Figure 5 As shown, a sample-based maneuvering actuator can be part of the route planning system architecture of an autonomous vehicle. Given a maneuvering description, the maneuvering actuator calculates one or more implementations of the AV (e.g., also referred to as "trajectory" hereinafter) in real time based on the AV's capabilities and AV motion constraints. The output of the actuator is a continuous trajectory, which represents how the AV will move in the near future (e.g., the next 10 ms). In the embodiment, the maneuvering is described as a combination of station-time (e.g., drivable area) and station-space-time constraints (e.g., longitudinal and lateral clearances).

[0046] Given a motion model (e.g., a kinematic bicycle model), dynamic station-time constraints and station-space-time constraints, and an objective function, the implementer iteratively and continuously solves the initialization-related optimization problem with respect to the motion model and constraints. Since the optimization is directly discretized in time, it allows sampling of the station-time constraints without loss of information (i.e., without approximations).

[0047] In this embodiment, the station-space-time constraint is parameterized by two variables: the station and time along the baseline trajectory. Since the sampling location is unknown in the first iteration of the optimization, a fast, initial-independent point-quality longitudinal rate optimization problem is first solved, which includes the distribution constraints of passenger comfort and the homotopy station-time constraint (hereinafter also referred to as "initial optimization"). In addition to the sampling approximation, the initial guess of the optimization solver is also computed.

[0048] Following the initial optimization, an iterative optimization is solved using the initial guesses from the initial optimization. This iterative optimization includes station constraints, spatial constraints, a motion model, and comfort objectives (e.g., acceleration / deceleration and maximum rate). In an embodiment, the iterative optimization converges when the resulting trajectory satisfies all specified constraints (without sampling). Due to the initial optimization, a single iteration of the optimization may be sufficient to generate a trajectory that satisfies the constraints imposed by the maneuver description and the comfort constraints for the well-posed problem.

[0049] Using the aforementioned optimizations, multiple AV trajectories that satisfy the dynamic and physical constraints of the AV are calculated. These trajectories can be fed to a trajectory score generator, which evaluates (e.g., scores) the trajectories using one or more rulebooks, one or more machine learning models, and / or one or more safety maneuvering action models. The evaluation results are then used to select the trajectory that best conforms to the rules in one or more rulebooks.

[0050] The selected trajectory is parameterized in time and input into the tracking controller, which implements an MPC class formulation with constraints on control inputs and states. This allows the tracking controller to query the precise desired position of the AV at a given time.

[0051] System Overview

[0052] Figure 1 An example of an autonomous vehicle 100 with autonomous capabilities is shown.

[0053] As used herein, the term “autonomy” refers to a function, feature, or facility that enables a vehicle to operate partially or fully without real-time human intervention, including but not limited to fully autonomous vehicles, highly autonomous vehicles, and conditionally autonomous vehicles.

[0054] As used in this article, an autonomous vehicle (AV) is a vehicle with autonomous capabilities.

[0055] As used in this article, "vehicle" includes any mode of transport for goods or people. Examples include cars, buses, trains, airplanes, drones, trucks, ships, vessels, submersibles, spacecraft, motorcycles, bicycles, etc. Driverless cars are an example of vehicles.

[0056] As used herein, a “track” refers to a path or route that moves an AV from a first spatiotemporal location to a second spatiotemporal location. In embodiments, the first spatiotemporal location is referred to as the initial location or starting point, and the second spatiotemporal location is referred to as the destination, final location, target, target location, or target position. In some examples, a track consists of one or more segments (e.g., segments of a road), and each segment consists of one or more blocks (e.g., a lane or part of an intersection). In embodiments, spatiotemporal locations correspond to real-world locations. For example, a spatiotemporal location is a pick-up or drop-off point for people or goods to board or alight.

[0057] As used in this paper, “implementation” refers to the trajectory generated by the sample-based maneuvering implementer described in this paper.

[0058] A "maneuver" is a change in the position, speed, or heading of an AV. An AV maneuver is a trajectory, but not all trajectories are maneuvers. For example, an AV trajectory in which the AV travels at a constant speed on a straight path is not a maneuver.

[0059] As used herein, “(one or more) sensors” includes one or more hardware components for detecting information relating to the environment surrounding the sensor. Some hardware components may include sensing components (e.g., image sensors, biometric sensors), transmission and / or receiving components (e.g., laser or radio frequency wave transmitters and receivers), electronic components (such as analog-to-digital converters), data storage devices (such as RAM and / or non-volatile memory), software or firmware components, and data processing components (such as application-specific integrated circuits), microprocessors, and / or microcontrollers.

[0060] As used in this article, a "road" is a physical area that can be traversed by vehicles and can correspond to a named passageway (e.g., a city street, an interstate highway, etc.) or an unnamed passageway (e.g., a driveway within a house or office building, a section of a parking lot, a section of an vacant parking lot, a waste disposal area in a rural area, etc.). Because some vehicles (e.g., four-wheel drive pickup trucks, SUVs, etc.) can traverse a variety of physical areas that are not particularly suitable for vehicle travel, a "road" can be any physical area that is not formally defined as a passageway by any municipality or other government or administrative agency.

[0061] As used herein, a “lane” is the portion of a road that can be traversed by vehicles and may correspond to most or all of the space between lane markings, or only a portion of the space between lane markings (e.g., less than 50%). For example, a road with lane markings spaced far apart may accommodate two or more vehicles, allowing one vehicle to overtake another without crossing the lane markings; therefore, it can be interpreted as a lane being narrower than the space between lane markings, or as having two lanes. Lanes can also be interpreted in the absence of lane markings. For example, a lane may be defined based on the physical characteristics of the environment (e.g., rocks in a rural area and trees along a road).

[0062] As used herein, a "rulebook" is a data structure that implements a priority structure for a set of rules arranged based on relative importance, wherein for any particular rule in the priority structure, one or more rules having a lower priority in the structure than that particular rule in the priority structure have lower importance than that particular rule. Possible priority structures include, but are not limited to: hierarchical structures (e.g., a general or partial order of rules), non-hierarchical structures (e.g., a weighted system of rules), or hybrid priority structures in which subsets of rules are hierarchical, but the rules within each subset are non-hierarchical. Rules may include traffic regulations, safety rules, ethical rules, local cultural rules, passenger comfort rules, and any other rules that can be used to evaluate the trajectory of a vehicle provided by any source (e.g., humans, texts, procedures, websites).

[0063] As used herein, “vehicle itself” or “itself” refers to a virtual vehicle or AV having virtual sensors for sensing a virtual environment, which is used, for example, by a planner to plan the route of the virtual AV in the virtual environment.

[0064] "One or more" includes functions performed by a single element, functions performed by multiple elements, such as in a distributed manner, several functions performed by a single element, several functions performed by several elements, or any combination of the foregoing.

[0065] It will also be understood that, although in some cases the terms “first,” “second,” etc., are used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the various described embodiments, a first contact may be referred to as a second contact, and similarly, a second contact may be referred to as a first contact. Both the first contact and the second contact are contacts, but they are not the same contact.

[0066] The terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the various embodiments described and the appended claims, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will also be understood that “and / or” as used herein refers to and includes any and all possible combinations of one or more of the relevant list items. It will also be understood that when the terms “comprising,” “including,” “possessing,” and / or “having” are used in this specification, they specifically indicate the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0067] As used herein, depending on the context, the term "if" may optionally be understood as meaning "when" or "at that time" or "in response to being determined" or "in response to being detected." Similarly, depending on the context, the phrase "if determined" or "if [the stated condition or event] has been detected" may optionally be understood as meaning "when determined" or "in response to being determined" or "when [the stated condition or event] is detected" or "in response to being detected."

[0068] As used herein, an AV system refers to an AV and an array of hardware, software, stored data, and real-time generated data that support AV operation. In embodiments, the AV system is incorporated within an AV. In embodiments, the AV system is distributed across several locations. For example, some of the software of the AV system is similar to that described below. Figure 3 The cloud computing environment described is implemented in the cloud computing environment of 300.

[0069] Generally, this document describes techniques applicable to any vehicle with one or more autonomous capabilities, including fully autonomous vehicles, highly autonomous vehicles, and conditionally autonomous vehicles, such as so-called Level 5, Level 4, and Level 3 vehicles, respectively (see SAE International Standard J3016: Classification and Definition of Terms Related to Automated Driving Systems for Motor Vehicles on Roads, the entire contents of which are incorporated herein by reference for further details on vehicle autonomy levels). The techniques described in this document are also applicable to partially autonomous vehicles and driver-assisted vehicles, such as so-called Level 2 and Level 1 vehicles (see SAE International Standard J3016: Classification and Definition of Terms Related to Automated Driving Systems for Motor Vehicles on Roads). In embodiments, one or more Level 1, Level 2, Level 3, Level 4, and Level 5 vehicle systems may automatically perform certain vehicle operations (e.g., steering, braking, and map usage) under certain operating conditions based on the processing of sensor inputs. The techniques described in this document can benefit vehicles of any level, ranging from fully autonomous vehicles to human-operated vehicles.

[0070] refer to Figure 1 The AV system 120 enables the AV 100 to operate along a trajectory 198, traversing the environment 190 to a destination 199 (sometimes referred to as the final location), while avoiding objects (e.g., natural obstacles 191, vehicles 193, pedestrians 192, cyclists and other obstacles) and complying with road rules (e.g., operating rules or driving preferences).

[0071] In one embodiment, the AV system 120 includes means 101 for receiving and operating operation commands from a computer processor 146. In another embodiment, the computer processor 146 is referenced below. Figure 3 The processor 304 described is similar. Examples of the device 101 include a steering controller 102, a brake 103, a gear, an accelerator pedal or other acceleration control mechanism, a windshield wiper, a side door lock, a window controller, and a turn indicator.

[0072] In an embodiment, the AV system 120 includes sensors 121 for measuring or inferring attributes of the state or condition of the AV 100, such as the AV's position, linear velocity and acceleration, angular velocity and acceleration, and heading (e.g., the direction of the front of the AV 100). Examples of sensors 121 are a Global Navigation Satellite System (GNSS) receiver, an inertial measurement unit (IMU) for measuring both linear acceleration and angular rate of a vehicle, a wheel rate sensor for measuring or estimating wheel slip ratio, a wheel braking pressure or braking torque sensor, an engine torque or wheel torque sensor, and a steering angle and angular rate sensor.

[0073] In an embodiment, sensor 121 also includes sensors for sensing or measuring properties of the AV's environment. Examples include a monocular or stereo camera 122 with visible, infrared, or thermal (or both) spectra, a LiDAR 123, a RADAR, an ultrasonic sensor, a time-of-flight (TOF) depth sensor, a rate sensor, a temperature sensor, a humidity sensor, and a precipitation sensor.

[0074] In one embodiment, the AV system 120 includes a data storage unit 142 and a memory 144 for storing machine instructions associated with a computer processor 146 or data collected by the sensor 121. In another embodiment, the data storage unit 142 is associated with the following... Figure 3 The described ROM 308 or storage device 310 is similar. In this embodiment, memory 144 is similar to main memory 306 described below. In this embodiment, data storage unit 142 and memory 144 store historical, real-time, and / or predictive information about environment 190. In this embodiment, the stored information includes maps, driving performance, traffic congestion updates, or weather conditions. In this embodiment, data related to environment 190 is transmitted from remote database 134 to AV 100 via a communication channel.

[0075] In an embodiment, AV system 120 includes communication devices 140 for transmitting measured or inferred attributes of the state and conditions of other vehicles, such as position, linear velocity and angular velocity, linear acceleration and angular acceleration, and linear heading and angular heading, to AV 100. These devices include vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication devices, as well as devices for wireless communication via point-to-point or ad hoc networks, or both. In an embodiment, communication device 140 communicates across the electromagnetic spectrum (including radio and optical communications) or other media (e.g., air and acoustic media). Combinations of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) communication (and in some embodiments, one or more other types of communication) are sometimes referred to as vehicle-to-all-things (V2X) communication. V2X communication typically conforms to one or more communication standards for communication with and between autonomous vehicles.

[0076] In an embodiment, the communication device 140 includes a communication interface. For example, this may be a wired, wireless, WiMAX, Wi-Fi, Bluetooth, satellite, cellular, optical, near-field, infrared, or radio interface. The communication interface transmits data from a remote database 134 to the AV system 120. In an embodiment, the remote database 134 is embedded in, for example... Figure 2In the cloud computing environment 200 described herein, communication interface 140 transmits data collected from sensor 121 or other data related to the operation of AV 100 to remote database 134. In some embodiments, communication interface 140 transmits information related to teleoperation to AV 100. In some embodiments, AV 100 communicates with other remote (e.g., "cloud") servers 136.

[0077] In this embodiment, the remote database 134 also stores and transmits digital data (e.g., data such as road and street locations). This data is stored in memory 144 on the AV 100 or transmitted from the remote database 134 to the AV 100 via a communication channel.

[0078] In one embodiment, the remote database 134 stores and transmits historical information (e.g., speed and acceleration distribution) related to the driving attributes of vehicles that previously traveled along trajectory 198 at similar times of day. In one implementation, such data may be stored in memory 144 on the AV 100 or transmitted from the remote database 134 to the AV 100 via a communication channel.

[0079] The computing device 146 located on AV 100 generates control actions in an algorithmic manner based on both real-time sensor data and prior information, allowing AV system 120 to perform its autonomous driving capabilities.

[0080] In one embodiment, the AV system 120 includes a computer peripheral device 132 coupled to a computing device 146 for providing information and alerts to a user of the AV 100 (e.g., an occupant or a remote user) and receiving input from that user. In another embodiment, the peripheral device 132 is similar to the one described in the following reference. Figure 3 The discussed display 312, input device 314, and cursor controller 316 are coupled wirelessly or wiredly. Any two or more interface devices can be integrated into a single device.

[0081] Example cloud computing environment

[0082] Figure 2 Example of a "cloud" computing environment. Cloud computing is a service delivery model that enables convenient, on-demand access over a network to a shared pool of configurable computing resources, such as networks, network bandwidth, servers, processing power, memory, storage, applications, virtual machines, and services. In a typical cloud computing system, one or more large cloud data centers house the machines used to deliver the services provided by the cloud. Now refer to... Figure 2The cloud computing environment 200 includes cloud data centers 204a, 204b, and 204c interconnected via cloud 202. Data centers 204a, 204b, and 204c provide cloud computing services to computer systems 206a, 206b, 206c, 206d, 206e, and 206f connected to cloud 202.

[0083] A cloud computing environment 200 includes one or more cloud data centers. Generally, a cloud data center (e.g.) Figure 2 The cloud data center 204a shown refers to the cloud (e.g., Figure 2 The physical arrangement of servers in cloud 202 (or a specific portion of the cloud) is illustrated. For example, servers are physically arranged in rooms, groups, rows, and racks within a cloud data center. A cloud data center has one or more regions, each containing one or more server rooms. Each room has one or more rows of servers, and each row includes one or more racks. Each rack includes one or more individual server nodes. In some implementations, servers in regions, rooms, racks, and / or rows are arranged into groups based on the physical infrastructure requirements of the data center facility, including power, energy, heat, heat sources, and / or other requirements. In this embodiment, server nodes are similar to... Figure 3 The computer system described herein. Data center 204a has many computing systems distributed across multiple racks.

[0084] Cloud 202 includes cloud data centers 204a, 204b, and 204c, and networks and network resources (e.g., network devices, nodes, routers, switches, and network cables) for connecting cloud data centers 204a, 204b, and 204c and facilitating access to cloud computing services by computing systems 206a-f. In embodiments, the network represents one or more local area networks, wide area networks, or any combination of wired or wireless networks coupled using terrestrial or satellite connections. Data exchanged over the network is transmitted using various network layer protocols, such as Internet Protocol (IP), Multiprotocol Label Switching (MPLS), Asynchronous Transfer Mode (ATM), Frame Relay, etc. Furthermore, in embodiments where the network represents a combination of multiple subnetworks, different network layer protocols are used on each underlying subnetwork. In some embodiments, the network represents one or more interconnected internetworks (such as the public Internet).

[0085] The computing system 206a-f or cloud computing service consumer connects to the cloud 202 via a network link and a network adapter. In embodiments, the computing system 206a-f is implemented as various computing devices, such as servers, desktops, laptops, tablets, smartphones, Internet of Things (IoT) devices, autonomous vehicles (including cars, drones, space shuttles, trains, buses, etc.), and consumer electronics. In embodiments, the computing system 206a-f is implemented in other systems or as part of other systems.

[0086] Computer System

[0087] Figure 3 Example: Computer system 300. In implementation, computer system 300 is a dedicated computing device. The dedicated computing device is hardwired to perform these technologies, or includes a digital electronic device such as one or more application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) that is persistently programmed to perform the aforementioned technologies, or may include one or more general-purpose hardware processors programmed to perform these technologies according to program instructions in firmware, memory, other memory, or a combination thereof. Such a dedicated computing device may also combine custom hardwired logic, ASICs, or FPGAs with custom programming to accomplish these technologies. In various embodiments, the dedicated computing device is a desktop computer system, a portable computer system, a handheld device, a network device, or any other device that includes hardwired and / or program logic to implement these technologies.

[0088] In an embodiment, computer system 300 includes a bus 302 or other communication mechanism for conveying information, and a hardware processor 304 coupled to the bus 302 to process information. The hardware processor 304 is, for example, a general-purpose microprocessor. Computer system 300 also includes main memory 306, such as random access memory (RAM) or other dynamic storage device, coupled to the bus 302 to store information and instructions executed by processor 304. In one implementation, main memory 306 is used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 304. When these instructions are stored in a non-transitory storage medium accessible to processor 304, computer system 300 becomes a dedicated machine customized to perform the operations specified in the instructions.

[0089] In an embodiment, the computer system 300 further includes a read-only memory (ROM) 308 or other static storage device coupled to the bus 302 for storing static information and instructions of the processor 304. A storage device 310, such as a disk, optical disk, solid-state drive, or three-dimensional cross-point memory, is provided and coupled to the bus 302 to store information and instructions.

[0090] In this embodiment, the computer system 300 is coupled via a bus 302 to a display 312, such as a cathode ray tube (CRT), liquid crystal display (LCD), plasma display, light-emitting diode (LED) display, or an organic light-emitting diode (OLED) display for displaying information to a computer user. An input device 314, including alphanumeric keys and other keys, is coupled to the bus 302 for transmitting information and command selections to the processor 304. Another type of user input device is a cursor controller 316, such as a mouse, trackball, touchscreen, or cursor arrow keys, for transmitting directional information and command selections to the processor 304 and for controlling the movement of the cursor on the display 312. Such input devices typically have two degrees of freedom on two axes (a first axis (e.g., the x-axis) and a second axis (e.g., the y-axis)), which allow the device to specify a position in a plane.

[0091] According to one embodiment, the techniques described herein are executed by computer system 300 in response to processor 304 executing one or more sequences of one or more instructions contained in main memory 306. These instructions are read into main memory 306 from another storage medium, such as storage device 310. Executing the sequence of instructions contained in main memory 306 causes processor 304 to perform the process steps described herein. In alternative embodiments, hardwired circuitry is used instead of or in combination with software instructions.

[0092] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs, magnetic disks, solid-state drives, or three-dimensional cross-point memory such as storage device 310. Volatile media include dynamic memory, such as main memory 306. Common forms of storage media include, for example, floppy disks, floppy disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with perforations, RAM, PROMs and EPROMs, FLASH-EPROMs, NV-RAMs, or any other memory chips or memory cartridges.

[0093] Storage media differ from transmission media, but can be used in conjunction with them. Transmission media participate in the information transmission between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, which include wires with a bus 302. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0094] In embodiments, various forms of media involve carrying one or more sequences of one or more instructions to processor 304 for execution. For example, these instructions may initially be executed on a disk or solid-state drive of a remote computer. The remote computer loads the instructions into its dynamic memory and transmits them over a telephone line using a modem. A local modem of computer system 300 receives data over the telephone line and converts the data into an infrared signal using an infrared transmitter. An infrared detector receives the data carried in the infrared signal, and appropriate circuitry places the data on bus 302. Bus 302 carries the data to main memory 306, from which processor 304 retrieves and executes the instructions. The instructions received by main memory 306 may optionally be stored on storage device 310 before or after execution by processor 304.

[0095] Computer system 300 also includes a communication interface 318 coupled to bus 302. Communication interface 318 provides bidirectional data communication coupled to network link 320 connected to local network 322. For example, communication interface 318 is an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem used to provide data communication connectivity with a corresponding type of telephone line. As another example, communication interface 318 is a Local Area Network (LAN) card used to provide data communication connectivity with a compatible LAN. In some implementations, a wireless link is also implemented. In any such implementation, communication interface 318 transmits and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

[0096] Network link 320 typically provides data communication to other data devices via one or more networks. For example, network link 320 provides connectivity to host computer 324 or to a cloud data center or device operated by Internet Service Provider (ISP) 326 via local network 322. ISP 326, in turn, provides data communication services via a worldwide packet data communication network now commonly referred to as the "Internet" 328. Both local network 322 and Internet 328 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks and signals on network link 320 via communication interface 318 are example forms of transmission media carrying digital data entering and leaving computer system 300. In embodiments, network 320 includes the aforementioned cloud 202 or a portion of cloud 202.

[0097] Computer system 300 sends messages and receives data including program code through one or more networks, network links 320, and communication interfaces 318. In an embodiment, computer system 300 receives code for processing. The received code is executed by processor 304 upon receipt and / or stored in storage device 310, or in other non-volatile storage devices for later execution.

[0098] Autonomous Vehicle Architecture

[0099] Figure 4 This illustrates the use of autonomous vehicles (e.g., Figure 1 The example architecture 400 of the AV 100 shown is illustrated. Architecture 400 includes a sensing module 402 (sometimes called a sensing circuit), a planning module 404 (sometimes called a planning circuit), a control module 406 (sometimes called a control circuit), a positioning module 408 (sometimes called a positioning circuit), and a database module 410 (sometimes called a database circuit). Each module plays a role in the operation of the AV 100. Commonly, modules 402, 404, 406, 408, and 410 can be... Figure 1 This is part of the AV system 120 shown. In some embodiments, any of modules 402, 404, 406, 408, and 410 is a combination of computer software (e.g., executable code stored on a computer-readable medium) and computer hardware (e.g., one or more microprocessors, microcontrollers, application-specific integrated circuits (ASICs), hardware memory devices, other types of integrated circuits, other types of computer hardware, or any or all combinations of these hardware).

[0100] In use, the planning module 404 receives data representing the destination 412 and determines data representing the trajectory 414 (sometimes called the route) that the AV 100 can travel to reach (e.g., arrive at) the destination 412. In order for the planning module 404 to determine the data representing the trajectory 414, the planning module 404 receives data from the sensing module 402, the positioning module 408, and the database module 410.

[0101] The sensing module 402 is used, for example, as follows Figure 1 One or more sensors 121 are shown to identify nearby physical objects. The objects are classified (e.g., grouped into types such as pedestrians, bicycles, cars, traffic signs, etc.), and a scene description including the classified objects 416 is provided to the planning module 404.

[0102] The planning module 404 also receives data representing the location 418 of the AV from the positioning module 408. The positioning module 408 determines the location of the AV by using data from the sensor 121 and data (e.g., geographic data) from the database module 410. For example, the positioning module 408 uses data from a GNSS receiver and geographic data to calculate the longitude and latitude of the AV. In embodiments, the data used by the positioning module 408 includes high-precision maps with lane geometry properties, maps describing road network connectivity properties, maps describing lane physical properties (such as traffic speed, traffic volume, number of vehicle and bicycle lanes, lane width, lane traffic direction, or lane marking type and location, or combinations thereof), and maps describing the spatial locations of road features (such as intersections, traffic signs, or various types of other traffic signals).

[0103] The control module 406 receives data representing trajectory 414 and data representing AV position 418, and operates the AV's control functions 420a-420c (e.g., steering, throttle, braking, ignition) in a manner that will cause the AV 100 to travel along trajectory 414 to reach destination 412. For example, if trajectory 414 includes a left turn, the control module 406 will operate the control functions 420a-420c in such a way that the steering angle of the steering function will cause the AV 100 to turn left, and the throttle and brake will cause the AV 100 to pause before turning and wait for passing pedestrians or vehicles.

[0104] In this embodiment, any one of the aforementioned modules 402, 404, 406, and 408 can send a request to the rule-based trajectory verification system 500 to verify the planned trajectory and receive the trajectory score, as shown in the reference. Figures 5 to 13 A more detailed description.

[0105] Sample-based motion actuator

[0106] Figure 5 This is a block diagram of a planning system 500 according to one or more embodiments. System 500 includes a route planner 501, a logic constraint generator 502, a homotopy extractor 503, a sample-based maneuvering actuator 504, a trajectory score generator 505, a tracking controller 506, and an AV 507.

[0107] In this embodiment, the route planner 501: 1) receives the initial and final states of AV 507; 2) uses a lane planner to form a desired sequence of geometric blocks of road data (barriers) for the lane; 3) divides the route into segments based on lane changes, such that the segments do not contain lane changes; 4) selects the segment in which AV 507 is located based on the physical state of the AV projected onto the barrier (obtained from the dynamic world model 508); 5) extracts the anchor path of the selected segment (which can be labeled as the "desired" anchor in the case of a desired lane change); and 6) trims the anchor path based on the maximum / minimum length. If no lane change is required, adjacent anchor paths are extracted and labeled only as "optional," meaning that AV 507 can use that lane (if needed) to avoid a collision.

[0108] In one embodiment, route planner 501 generates a graphical representation of the operating environment of AV 507, the physical state of AV 507 (e.g., speed, position) based on sensor data, and possible outcomes. In this embodiment, the graphical representation is a decision graph comprising multiple nodes, where each node represents a sample of the decision space for AV 507 in a specific driving scenario, such as multiple maneuvers related to other vehicles and objects, and environmental constraints (e.g., drivable areas, lane markings). The edges of the decision graph represent different trajectories available to AV 507 for a specific driving scenario.

[0109] In an embodiment, the logic constraint generator 502 includes generating at least one of "hard" constraints and "soft" constraints. Hard constraints are logic constraints that must not be violated because if violated, the AV will collide with other objects (such as pedestrians who might "cross" the road). Note that a hard constraint does not mean "no collision." Rather, a hard constraint can be, for example, a combination of space and speed constraints that could lead to a collision. For example, a hard constraint can be expressed in words as: "If the AV travels at 30 mph in lane A or accelerates at 2 mph / s in lane B, it will collide with a pedestrian." Therefore, formally expressed hard constraints are "do not travel at 30 mph in lane A" and "do not exceed 25 mph in lane A."

[0110] Soft constraints are constraints that an AV should follow but can be violated to, for example, complete its journey to its destination or avoid a collision. Some examples of “soft” constraints include, but are not limited to, passenger comfort constraints and minimum thresholds for lateral clearance with pedestrians crossing the street (jaywalking), used to ensure the comfort of both the pedestrian and the AV passengers in the event of AV maneuvering. In embodiments, soft constraints may be embodied in one or more hierarchical or non-hierarchical rulebooks. Soft constraints may include time-varying spatial constraints (e.g., lanes that open as traffic proceeds). Spatial constraints may be drivable areas.

[0111] In some embodiments, different constraints are sampled differently. For example, the homotopy extractor 503 can operate at 10 Hz, and the search can be performed twice as fast as 20 Hz.

[0112] In an embodiment, homotopy extractor 503 generates a set of potential maneuvers for the AV. Instead of assuming a target and then selecting the target that results in the lowest cost, homotopy extractor 503 assumes a set of activity constraints (referred to as "homtopy" (defined below)) and then selects the set of constraints that results in the lowest cost. Homotopy extractor 503 receives a route plan containing "anchor paths" from route planner 501. An "anchor path" is the best estimate of the lane in which the AV is located and is an alternative path (potentially desired path) that the AV can use when making a lane change. In an embodiment, the route plan also includes spatial constraints of the sum of squared rates calculated (e.g., calculated using a boundary generator) along the anchor path.

[0113] Given the initial state of AV 507, the final state of AV 507 on the anchor path, and map representations and predictions of other agents in the scene, the homotopy extractor 503 finds all “approximately” feasible maneuvers that AV can perform. Note that in this context, the resulting maneuvers may not be dynamically feasible, but the homotopy extractor 503 guarantees that the resulting set of constraints describing the maneuvers is not empty (also considering the AV footprint). AV maneuvers are described by homotopy, which is the unique space where any path starting from the initial AV state and ending with the final AV state can be continuously deformed. To find these maneuvers, the homotopy extractor 503 iterates over all possible decisions that AV can make relative to other agents (e.g., passing to the left / right, before or after, or only after). In short, the output of the homotopy extractor 503 describes the spatiotemporal location of AV to the agents. Although this may be a computationally expensive search, all infeasible combinations can be eliminated due to a simple set of checks. Homotopic extractor 503 is described in further detail in the co-pending application entitled “Homotopic-Based Planner for Autonomous Vehicles” (Representative Case No. 46154-0261001), filed on December 7, 2021 (the entire contents of which are incorporated herein by reference).

[0114] In order to describe the constraints representing where other agents are located and what collisions between the AV and these agents mean, each agent is transformed into a station-time obstacle or a station-space-time obstacle, as referenced. Figure 7A and 7B As described, station-time constraints are constraints parameterized over time, while station-space-time constraints are constraints parameterized over both station and time.

[0115] In this embodiment, the search 504a…504n is performed by a sample-based maneuvering implementer 504 to generate a set of trajectories 1…N of all extracted homotopies provided by the homotopy extractor 503. The sample-based maneuvering implementer 504 finds an implementation (also referred to herein as a trajectory) that satisfies the constraints imposed by the homotopy while maximizing passenger comfort. Given a single homotopy, the sample-based maneuvering implementer 504 dynamically generates feasible trajectory implementations within that homotopy. Reference Figures 6 to 13 The sample-based maneuvering actuator 504 is described in further detail. Example techniques for generating maneuvers and / or trajectories are also described in further detail in a co-pending application entitled “Vehicle Operation Using ManuverGeneration” (Agency No. 46154-0316001), filed December 7, 2021, the entire contents of which are incorporated herein by reference.

[0116] In an embodiment, the trajectory score generator 505 uses one or more rulebooks, one or more machine learning models 509, and / or one or more safe maneuver action models 510 to score trajectories 1…N, and uses the scores to select the trajectory that best conforms to the rules in one or more rulebooks.

[0117] In this embodiment, a predefined cost function is used to generate trajectory scores. For example, a total or partial order hierarchical cost function can be used to score trajectories. The cost function is applied to a metric (e.g., a Boolean value) associated with a rule hierarchy in one or more rulebooks that is violated and / or satisfied, based on priority or relative importance. An example hierarchy of priority-based rules is as follows (from top to bottom): collision avoidance (Boolean), congestion (Boolean), desired final state in the lane (Boolean), lane change (Boolean), and passenger comfort (double floating-point). In this example, each non-zero priority rule is defined as a Boolean to avoid over-optimization of high-priority costs. The most important or highest priority rule is collision avoidance, followed by congestion avoidance, followed by desired final state in the lane avoidance, followed by lane change, and then comfort rules (e.g., maximum acceleration / deceleration). These example rules are described more fully below:

[0118] Collision: Set to true if there is a state along the scoring trajectory where the footprint of the AV vehicle collides with the footprint of any other agent (e.g., they are considered to collide if their polygons intersect).

[0119] Blocked: A trajectory is considered blocked if the final homotopy does not contain the desired target state and the final velocity of the trajectory is below a specified threshold (e.g., 2 m / s).

[0120] Final state in desired lane: Set to true if the final state of the trajectory is found in the lane where the desired lane change occurs, and set to true if the AV 507’s footprint crosses a lane divider at any time during the scored trajectory.

[0121] Comfort: Consider the maximum values ​​of acceleration / deceleration, braking distance, and longitudinal and lateral clearances.

[0122] For each trajectory, the rules are examined and a metric is determined. The metric is used to formulate a cost function, which is then minimized using, for example, least squares formulation or any other suitable solver. The trajectory with the lowest cost is the selected trajectory, i.e., the trajectory with the fewest rule violations or the best compliance. Note that the rules described above are merely examples. Those skilled in the art will recognize that any suitable cost function and rulebook can be used for trajectory scoring, including rulebooks with more or fewer rules.

[0123] The tracking controller 506 is used to improve the robustness of system 500 to unexpected spikes in computational demands. The tracking controller 506 is a fast-acting controller that provides stable and smooth control input and allows system 500 to react more quickly to disturbances. In this embodiment, the tracking controller 506 operates at 40 Hz. The input to the tracking controller 506 is a time-parameterized selected trajectory provided by the trajectory fraction generator 505, allowing the tracking controller 506 to query the precise desired position of the AV at a given time.

[0124] In this embodiment, the tracking controller 506 is configured for an MPC class problem with constraints on control inputs and states, and exhibits some differences from conventional continuous MPC. However, any suitable multivariate control algorithm can also be used. The MPC class is configured using a motion model, a cost function J over a predetermined range, and an optimization algorithm for minimizing the cost function J using the control input u. An example cost function used for optimization is a quadratic cost function.

[0125] In this embodiment, the dynamic model is a kinematic vehicle model in Cartesian coordinates or any other suitable reference coordinate system. For example, as a reference... Figure 8 More fully described, the kinematic vehicle model could be a bicycle model, which allows for a geometrically defined sideslip angle to represent the yaw rate based on a variable expressed as a representation of the center of gravity relative to the AV. In an embodiment, the cost function J follows a profile error formulation (orthogonal deviation from the anchor path), where the objective is to minimize lateral and longitudinal tracking errors. The control input u is not used in this formulation but is used for reference. Figure 9 In the longitudinal rate optimization problem described.

[0126] Figure 6Three different homotopies according to one or more embodiments and their corresponding implementations are illustrated. As previously defined, homotopy is the unique space in which any path that begins at an initial AV state and ends at a final AV state can be continuously deformed. (See reference...) Figure 8 Given a single homotopy, the sample-based maneuvering implementer 504 uses the MPC class to formulate a kinematically and / or dynamically feasible trajectory within that homotopy.

[0127] In this example, vehicle 601 is traveling in right lane 602 and is approaching object 603 (e.g., a parked vehicle) blocking right lane 602. Vehicles 604 and 605 are traveling in left lane 606. Vehicle 601 may decelerate and merge into left lane 606 behind vehicle 604 (homopy #1), accelerate in front of vehicle 604 and merge into left lane 606 behind vehicle 605 (homopy #2), or accelerate in front of vehicle 605 and merge into left lane 606 in front of vehicle 605 (homopy #3). These three maneuvers can be generated by homotopy extractor 503 by iterating over all possible decisions that vehicle 601 can make with respect to vehicles 604 and 605. The output of homotopy extractor 503 describes the temporal-spatial position of vehicle 601 relative to vehicles 604 and 605.

[0128] Figure 7A It is based on one or more embodiments for Figure 7B The image shows an example maneuver description of a pedestrian "crossing the road" scenario. The vertical axis represents station / position (meters), and the horizontal axis represents time (seconds). A maneuver description defines a precise and continuous vehicle maneuver. A maneuver is a combination of dynamic station-time and station-space-time constraints, where the station-space-time constraints explicitly include bias decisions and therefore proximity constraints. Some examples of station-time constraints are maximum speed and road constraints (e.g., all available lanes). Some examples of station-space-time constraints are drivable areas and longitudinal and lateral clearance distances with other agents. Figure 7B This is a BEV that illustrates an example spatial constraint for anchor path 705.

[0129] In this example scenario, a pedestrian obstacle 701 (hard or soft) "crosses" the road 702, and a vehicle 703 enters the anchor path tube 704 after decelerating at a comfortable rate. Therefore, the vehicle 703 will need to maneuver to avoid colliding with the pedestrian obstacle 701, but must also adhere to station-time and station-space-time constraints regarding the anchor path 705, including remaining within the drivable area 706 and maintaining desired longitudinal and lateral clearance distances from the pedestrian obstacle 701 and any other agents in the driving scenario (e.g., other moving or parked vehicles), as referenced. Figure 8 As stated above.

[0130] Figure 7A The example maneuvering description shown illustrates a maneuvering space that can be used by vehicle 703 to avoid collision with pedestrian obstacle 701. In this example, the maneuvering space 707 is a non-intersecting space defined by the gap area 709 of pedestrian obstacle 701 and the drivable area 706. Note that in Figure 7A In this context, area 708 represents a hard pedestrian obstacle, and area 709 represents a soft pedestrian obstacle. Therefore, area 708 (at the station and during time) indicates when the vehicle 703 will definitely collide with the pedestrian obstacle 701 if no avoidance maneuver is performed according to the maneuver description. Area 710 represents an avoidance maneuver involving entering the adjacent lane.

[0131] Imposing station-time and station-space-time constraints on each other yields a fully maneuverable description that can be continuously sampled along a defined time range, which greatly simplifies the architecture of the planning system 500. No further decisions are required, and the proximity constraints are directly expressed as continuous functions that can be used for optimization.

[0132] Figure 8 An example of an avoidance maneuver performed by a vehicle 801 to avoid a parked car 802 in the vehicle 801's driving lane, according to one or more embodiments, is illustrated. Specifically, proximity constraints are shown for both lateral and longitudinal displacements, where the longitudinal deviation d... lon Defined as the distance between the vehicle 801 and the parked car 802, and the lateral deviation d lat This is defined as the lateral distance between the vehicle 801 and the parked car 802. The N MPC class prediction steps k are shown as constraints in d. lon and d lat Inside.

[0133] In this embodiment, given the motion model, station-time and station-space-time constraints, and cost function, the trajectory optimization problem is solved by the tracking controller 506. In this embodiment, the trajectory optimization problem is solved according to the following equation [1] by formulating proximity constraints in the same manner as conventional MPC formulation: [1]

[0135]

[0136] In this embodiment, the optimization problem can be formulated in a state space defined in a curvilinear coordinate system, where the state is defined relative to the vehicle's center of gravity (CoG). Six relaxation variables are introduced as additional inputs to all soft constraints. In this example embodiment, the tracking controller 506 takes as input the time-parameterized selected trajectory output by the trajectory score generator 505. This means that the tracking controller 506 can query the AV at any time t. i Precise expected location Where s is the progress, n is the lateral error, and μ is the local heading (μ = ψ(yaw) - φ). s (pitch)), v is velocity, a is acceleration projected in the driving direction, and δ is steering angle. It is the steering ratio, and u is a vector of input variables including the sudden movement and the steering ratio. and It is a slack variable, where λ n It is a relaxation on the transverse tube, λ a It is relaxation in acceleration, λ s It is a slack in the progress, λ n,soft It is relaxation on the soft transverse tube, λ v,soft It is a relaxation in soft velocity. λ a,soft It is a relaxation of soft acceleration, and J stage () and J terminal () is the cost function. The equation can be solved using any suitable solver [1]. Other embodiments may use different trajectory optimization methods, including but not limited to learning-based methods or methods using control barrier functions.

[0137] In this embodiment, the motion model is a kinematic bicycle model, which allows for a geometrically defined sideslip angle β such that the vehicle's speed (v) x ,v y ) and yaw rate It can be expressed in terms of β, as shown in equation [2]:

[0138]

[0139] in

[0140]

[0141] Among them, l r It is the length from the front of the AV to the CoG of the vehicle, and l f It is the length from the rear of the vehicle to the CoG of the vehicle.

[0142] In the embodiment, the cost function J stage and J terminal It is given by the following formula:

[0143]

[0144] as well as

[0145] J terminal =J tracking (x N )+J slack (S N [5]

[0146] In this embodiment, only the first three states need to be tracked, and the comfort requirement applies to acceleration and both inputs. Both tracking and comfort objectives are implemented with quadratic costs. Relaxation violations are penalized by quadratic or linear costs.

[0147] J tracking =(xx) ref ) T Q(xx ref [6]

[0148]

[0149] Where Q = diag(q) s ,q n ,q μ ,0,0,0,0), And E = diag(s) nsoft ,s vsoft ,s asoft ) represents the weighting factors of each cost item.

[0150] Note that the formulation of equations [1] through [8] differs from that of conventional MPC, because MPC uses dynamic look-ahead to approximate bias decisions and samples spatial constraints using prediction time from MPC. However, the above-described MPC class formulation encodes constraints in the maneuver description (homotopy), so the tracking controller 506 does not need to make additional decisions or approximations.

[0151] In this embodiment, the rulebook defines high-level constraints that provide expected behavior for the vehicle. A process motion plan is received from a planning module (e.g., planning module 404), which generates a more refined implementation that considers the aforementioned motion model and cost function. One or more rules from the rulebook are considered in the MPC class optimization described above. The one or more rules specify the solution space for trajectory optimization defined by the process motion plan provided by planning module 404. In some embodiments, one or more rules, such as proximity rules, can be re-evaluated within the MPC formulation. Table I below provides examples of the rules employed.

[0152] Table I - Example Rulebook Constraints

[0153]

[0154] Linear inequality constraints

[0155] The example rulebook constraints described above are transformed into state constraints. The feasible set of states x∈X, inputs u∈U, and slack variables s∈S is represented by linear inequality constraints. Note that, by definition, slack variables are positive semidefinite. Linear inequality constraints are hard and do not allow relaxation, therefore they cannot control the violation of constraints. In the embodiment, the vehicle does not operate close to the boundaries of the state constraints:

[0156] [9]x min ≤x≤x max

[0157] u min ≤u≤u max

[0158] 0≤a≤a max

[0159] Nonlinear inequality constraints

[0160] More complex constraints can be imposed by using general inequality constraints. These more complex constraints can be nonlinear combinations of different states, inputs, and online specifyable variables. Typically, constraints are used on lateral position and velocity to generate a tube around the anchor path given by planning module 404. Slack variables are used in the formulation of these constraints to explicitly control and penalize violations. In this embodiment, the following nonlinear inequality constraints are defined:

[0161] c station (x,λ s )≤0,

[0162] c vel (x,λ vsoft )≤0

[0163] c tube_hard (x,λ n )≤0

[0164] c tube_soft (x,λ nsoft )≤0

[0165] c a_hard (x,λ a )≤0

[0166] c a_soft (x,λ asoft )≤0

[0167] c vel_prox (x,λ v )≤0

[0168] Figure 9 The diagram illustrates sampling of station-time constraints according to one or more embodiments. Because station-time constraints are not continuously differentiable, they need to be discretized by sampling (as indicated by vertical line 900), where each vertical line represents a sample at a specific time, thus discretizing the station-time constraints. Since the station-time constraints are already parameterized only in time, the corresponding MPC time step can be used. Note that sampling of station-time constraints does not lead to any approximations.

[0169] Figure 10 This illustrates sampling of space-station-time constraints according to one or more embodiments. Sampling space-station-time constraints is more complex than sampling station-time constraints that are parameterized only in time, because space-station-time constraints are parameterized in both time and station. The station component must be sampled a priori to construct the optimization problem. See reference... Figure 11 The solution to the longitudinal rate optimization problem can be used as an initial guess for optimization.

[0170] Figure 11 An example vertical implementation according to one or more embodiments is shown. In the embodiments, references are utilized. Figure 8 The optimization problem described above is initialized with the result of another optimization formulated by the MPC class (which solves faster than the optimization described above). In the initial optimization problem, a point-mass longitudinal problem (rate optimization) is solved using a double integrator with acceleration as a controllable input u. The initial optimization includes station rate distribution constraints and homotopy station-time constraints. This also allows acceleration constraints to be imposed in the optimization. For example, since the rate distribution constraints also take into account the curvature of the AV 507 path, the initial longitudinal guess will also indirectly limit the maximum lateral acceleration. Therefore, in addition to the stations used for sampling spatial constraints, the initial optimization provides initial guesses of the rate and acceleration of AV 507 for optimization.

[0171] Figures 12A to 12CThe results of homotopy optimization with two agents according to one or more embodiments are shown. Figure 12A In this context, the predicted motion of the vehicle 1201 is shown to be entirely within the station constraints, and therefore, it can accelerate quickly enough to make merging into the adjacent lane 1202 feasible. This can also be... Figure 12B As observed, the vehicle's acceleration is very high at the beginning of the prediction range and decreases slowly as the vehicle's speed increases. Figure 12B In the process, as the vehicle gets closer to the parked car in front of it, its speed decreases due to proximity constraints. Finally, Figure 12C The entire predicted trajectory 1203 of the vehicle 1200 is depicted, including predictions from two other agents 1204a and 1204b (e.g., other vehicles).

[0172] At this point, the large optimization problem is easy to solve because it consists only of station constraints, spatial constraints, a motion model, and a comfort objective. Due to spatial constraint sampling, the optimization problem is solved iteratively by resampling the spatial constraints using results from previous iterations. In the embodiment, the optimization problem is considered convergent if the optimized trajectory satisfies all the original constraints (without sampling). In appropriately formulated problems, convergence can occur in a single iteration.

[0173] Example processing

[0174] Figure 13 This is a flowchart of a process for rule-based trajectory evaluation according to one or more embodiments. Process 1300 can use, for example, as shown in the reference... Figure 3 The computer system 300 described is used to implement this.

[0175] Processing 1300 can begin by obtaining the maneuver description (1301) of the vehicle. The maneuver description describes the joint dynamic station-time constraints and station-space-time constraints of the vehicle. The dynamic station-time constraints are parameterized in time, and the dynamic station-space-time constraints are parameterized in both station and time.

[0176] Process 1300 involves sampling the dynamic station-time constraints and the dynamic station-space-time constraints (1302) (as referenced). Figures 5 to 8 (As described) to continue.

[0177] Process 1300 solves the optimization problem (1303) by using the sampled dynamic station-time constraints, the sampled dynamic station-space-time constraints, and the cost function of the motion model (see reference 1303). Figures 5 to 8 (as described) and continue.

[0178] Processing 1300 involves generating trajectories based on the solved optimization problem (as referenced). Figures 5 to 8 (as described) to continue, wherein the trajectory satisfies the dynamic station-time constraint and dynamic station-space-time constraint (1304) imposed by the description of the maneuver.

[0179] Processing 1300 continues by controlling the vehicle (1305) according to the trajectory.

[0180] In the preceding description, embodiments of the invention have been described with reference to numerous specific details, which may vary from implementation to implementation. Therefore, the specification and drawings should be considered illustrative rather than restrictive. The sole and exclusive indication of the scope of the invention, and what the applicant expects to be the scope of the invention, is the literal and equivalent scope of the claims published from this application in the specific form of the claims, including any subsequent amendments. Any definitions of terms expressly set forth herein for inclusion in such claims should be taken as meaning as such terms are used in the claims. Furthermore, when the term “comprising” is used in the preceding specification or appended claims, what follows that phrase may be an additional step or entity, or a sub-step / sub-entity of a previously stated step or entity.

[0181] Additional examples

[0182] The following provides an example implementation of the features described in this article.

[0183] Example 1: A method comprising: obtaining a maneuvering description of a vehicle using at least one processor, the maneuvering description describing a joint dynamic station-time constraint and a dynamic station-space-time constraint on the vehicle, wherein the dynamic station-time constraint is parameterized in time and the dynamic station-space-time constraint is parameterized in both station and time; sampling the dynamic station-time constraint and the dynamic station-space-time constraint using the at least one processor; solving an optimization problem using the at least one processor with the sampled dynamic station-time constraint, the sampled dynamic station-space-time constraint, and a cost function of a motion model; and generating a trajectory based on the solved optimization problem using the at least one processor, wherein the trajectory satisfies the dynamic station-time constraint and the dynamic station-space-time constraint imposed by the maneuvering description.

[0184] Example 2: According to the method described in Example 1, the dynamic station-space-time constraint explicitly includes bias decisions.

[0185] Example 3: According to any one of the preceding examples, the motion model is a kinematic bicycle model.

[0186] Example 4: The solution is continuous and iterative according to any one of the preceding examples.

[0187] Example 5: According to any one of the preceding examples, the continuous and iterative solution converges when the optimized trajectory satisfies the unsampled dynamic station-time constraint and the station-space-time constraint.

[0188] Example 6: According to the method of any one of the foregoing examples, the trajectory maximizes the comfort constraints imposed on the vehicle.

[0189] Example 7: The method according to any one of the foregoing examples further includes: using the at least one processor to solve a longitudinal rate optimization problem to determine where to begin sampling the dynamic station-time constraints and the dynamic station-space-time constraints.

[0190] Example 8: According to the method of any one of the preceding examples, the longitudinal rate optimization problem includes static rate distribution constraints and maneuver station-time constraints.

[0191] Example 9: According to any one of the preceding examples, the static rate distribution constraint limits the maximum lateral acceleration of the vehicle by taking into account path curvature.

[0192] Example 10: The method according to any one of the preceding examples provides an initial guess of the acceleration and velocity for solving the longitudinal velocity optimization problem.

[0193] Example 11: The method according to any one of the foregoing examples further includes: using a control circuit to initiate a maneuver of the vehicle based on the trajectory.

[0194] Example 12: A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform any one of Examples 1 to 11.

[0195] Example 13: A vehicle comprising: at least one processor; and a non-transitory computer-readable storage medium storing instructions which, when executed by the at least one processor, cause the at least one processor to perform any one of Examples 1 to 11.

[0196] Related applications

[0197] This application claims the benefit of U.S. Provisional Application Serial No. 63 / 142,871, filed January 28, 2021, the entire contents of which are incorporated herein by reference.

Claims

1. A method for a vehicle, comprising: A maneuvering description of the vehicle is obtained using at least one processor. This maneuvering description describes a combination of dynamic station-time constraints and dynamic station-space-time constraints for the vehicle, wherein the dynamic station-time constraints are parameterized in time, and the dynamic station-space-time constraints are parameterized in both station and time dimensions. The maneuvering description includes a two-dimensional representation having a first axis and a second axis orthogonal to the first axis, where the first axis represents time and the second axis represents station. The dynamic station-time constraints and the dynamic station-space-time constraints are represented as corresponding regions in the two-dimensional representation. The dynamic station-time constraints and the dynamic station-space-time constraints are sampled using the at least one processor. The optimization problem is solved using the at least one processor with sampled dynamic station-time constraints, sampled dynamic station-space-time constraints, and the cost function of the motion model, wherein the solution is continuous and iterative, and wherein the continuous and iterative solution converges if the optimized trajectory satisfies the unsampled dynamic station-time constraints and the station-space-time constraints. The at least one processor generates a trajectory based on the solved optimization problem, wherein the trajectory satisfies the dynamic station-time constraints and the dynamic station-space-time constraints imposed by the maneuver description; The at least one processor is used to solve the longitudinal rate optimization problem to determine where to begin sampling the dynamic station-time constraints and the dynamic station-space-time constraints.

2. The method according to claim 1, wherein the dynamic station-space-time constraint explicitly includes bias decisions.

3. The method according to claim 1, wherein, The motion model is a kinematic bicycle model.

4. The method according to claim 1, wherein, The trajectory maximizes the comfort constraints imposed on the vehicle.

5. The method according to claim 1, wherein, The longitudinal rate optimization problem includes static rate distribution constraints and maneuver station-time constraints.

6. The method according to claim 5, wherein, The static rate distribution constraint limits the maximum lateral acceleration of the vehicle by taking into account path curvature.

7. The method according to claim 1, wherein, The solution to the longitudinal velocity optimization problem provides an initial guess of the acceleration and velocity for solving the optimization problem.

8. The method according to claim 1, further comprising: The control circuit initiates the maneuvering of the vehicle based on the trajectory.

9. A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 8.

10. A vehicle, comprising: At least one processor; A non-transitory computer-readable storage medium storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 8.

11. A computer program product comprising a computer program that, when executed by a processor, performs the method according to any one of claims 1 to 8.

Images