SAFETY PROCEDURES ANALYSIS FOR OBSTACLE AVOIDANCE IN AN AUTONOMOUS VEHICLE

Abstract

Procedure, comprehensive: Determining a currently claimed set of points that is representative of a volume in an environment occupied by a vehicle at a given time, based at least partially on a size, position, and orientation of the vehicle; Generating one or more vehicle-occupied motion paths that are representative of first future claimed sets of points of the vehicle in the environment, if the vehicle were to implement a first safety procedure at that time, based at least partially on one or more speeds of the vehicle at that time and the first safety procedure for the vehicle; Detecting an intersection point between one or more vehicle-occupied movement paths and one or more object-occupied movement paths based at least partially on comparing the one or more vehicle-occupied movement paths with the one or more object-occupied movement paths, wherein the one or more object-occupied movement paths are representative of second future claimed sets of an object in the environment if the object were to implement a second safety procedure associated with the object at that time; Calculating a first safety potential assigned to the vehicle implementing the first safety procedure and the object implementing the second safety procedure, wherein the first safety potential is representative of the intersection point; and Execute, based at least in part on the intersection point, one of the first safety procedures or an alternative procedure which, when implemented by the vehicle when the object implements the second safety procedure, is intended to have a second safety potential calculated to have a lower probability of collision between the vehicle and the object than the first safety potential.

Description

BACKGROUND OF THE INVENTION

[0001] For autonomous vehicles to achieve levels 3-5 of autonomy (e.g., conditional automation (Level 3), high automation (Level 4), and full automation (Level 5), as defined in the Society of Automotive Engineers standard 13016), the autonomous vehicles must be able to operate safely in all environments without the need for human intervention when potentially unsafe situations arise. To meet this standard, obstacle and collision avoidance systems must be implemented in the autonomous vehicles that do not contribute to or increase the likelihood or imminent threat of a collision (e.g., with another human-operated vehicle outside the control of the autonomous vehicle).In addition, obstacle and collision avoidance systems should be implemented in a manner that feels natural to the occupants of the autonomous vehicles, so that the autonomous vehicle does not perform harsh, abrupt, or irregular safety procedures unless necessary to ensure the safety of the occupants.

[0002] However, conventional systems have yet to meet these standards. Conventional systems, such as systems that implement automatic emergency braking (AEB), analyze sensor information corresponding to what is in front of or behind the vehicle (e.g., along a vehicle's longitudinal axis) to determine whether to apply the brakes. Other conventional systems, such as systems that implement blind spot monitoring (BSM), analyze sensor information corresponding to what is on the sides of the vehicle (e.g., along a vehicle's transverse axis) to determine whether a lane change is safe. As a result, these conventional systems analyze the vehicle's longitudinal and transverse axes separately.This can lead to unnecessary restrictions on vehicle control and, when used by autonomous vehicles, limit the autonomous vehicles' ability to perform natural and / or required vehicle maneuvers (e.g., maneuvering into an adjacent lane in slow-moving traffic when another vehicle is alongside the autonomous vehicle). Furthermore, these conventional systems can only rely on information about objects in the current lane when analyzing a vehicle's current path in a current lane and, as a result, may be more limited in handling unforeseen conditions outside the current lane (e.g., in adjacent lanes, on the side of the road, and / or the like, such as fallen trees, occluded objects, etc.).

[0003] Furthermore, conventional systems may also require that a safety procedure (e.g., emergency braking) be used even in situations where it is not advantageous, or where there are more advantageous options than using the safety procedure (e.g., when executing a safety procedure, such as braking, increases the likelihood or imminent danger of a collision). In some of these conventional systems, there may be exceptions to account for this problem, which may be specified by rules and moderated by input information, such as lane structure, path structures based on map information, and / or the like.Even in those conventional systems that consider exceptions to the implementation of a safety procedure, there may still be reliance on a predetermined exception for navigating the specific scenario, allowing the autonomous vehicle to implement a different vehicle maneuver than the safety procedure. However, an exception cannot be created for every situation, so if an exception is not available, the safety procedure may be implemented, even though it represents a less safe outcome. To this end, these conventional systems may not be able to determine whether the safety procedure or one of the exceptions is actually the safest action to take.As a result, these conventional systems may identify a situation, determine whether an exception to the situation exists, and execute a procedure associated with the exception if the exception exists, thereby failing to take into account the relative overall safety of the various options when navigating the environment. BRIEF DESCRIPTION OF THE INVENTION

[0004] Embodiments of the invention relate to the analysis of safety procedures of a vehicle and objects in an environment for obstacle avoidance. Systems and methods are disclosed for obstacle avoidance using trajectories representative of forward-projected safety procedures to ensure that an autonomous vehicle is always capable of implementing the safety procedure to avoid collisions with objects in the environment.

[0005] In contrast to conventional systems such as those described above, the system according to the invention can calculate a safety potential (e.g., a measure of the probability or imminent danger of a collision occurring) for a safety procedure, use the safety potential as a basis, and then determine whether a different action or set of actions can be implemented to adjust the safety potential to reduce the probability of a collision occurring. As a result, exceptions and rules are not required for every situation because the system evaluates each situation, determines the safety potential for the safety procedure, and then determines whether to implement a set of controls representative of the safety procedure or another measure that exceeds the safety potential associated with the safety procedure.

[0006] To achieve this, the system can determine a state (e.g., a position, a speed, an orientation, a yaw rate, etc.) of a vehicle and a safety procedure associated with the vehicle. The system can further generate a virtual representation of points in space and time (e.g., two dimensions for space and one dimension for time) that the vehicle will occupy (e.g., one or more vehicle-occupied trajectories) when it executes the safety procedure. The system can then determine states and safety procedures for each object (sensed and unsensed, static and moving) in the environment and generate a virtual representation of the points in space and time that the objects will occupy (e.g., for each object, one or more object-occupied trajectories) when their respective safety procedures are executed.The system can then monitor the trajectory(s) occupied by the vehicle with respect to the trajectories occupied by the object to determine if an intersection or overlap is occurring. Once it is determined that an intersection or overlap is occurring, the system can implement a preemptive object avoidance procedure, which acts like a "safety force field" that proactively "ward" the vehicle away from the projected intersection point of the object(s) by implementing an action that reduces the overall probability or imminent threat of an actual collision between the vehicle and the object(s).

[0007] If, during implementation of the safety procedure or other measure, it is determined that an overlap between the vehicle-occupied trajectory(s) and the object-occupied trajectory(s) no longer exists (e.g., the imminent danger and / or probability of a collision is reduced), the system may stop implementing the safety procedure or other measure and return control to a higher layer of the system (e.g., a planning and / or control layer of an autonomous driving software stack) dedicated to controlling the vehicle according to normal driving protocols (e.g., obeying road rules, following current instructions, etc.). SHORT DESCRIPTION OF THE DRAWING

[0008] The present systems and methods for safety procedure analysis for obstacle avoidance in autonomous vehicles are described in more detail below with reference to the accompanying drawings, in which: Fig. 1 is a block diagram of an exemplary autonomous vehicle system, according to some embodiments of the invention; Fig. 2A is an example two-dimensional projection of a security procedure for a vehicle, according to some embodiments of the invention; Fig. 2B is another example of a two-dimensional projection of a safety procedure for a vehicle, according to some embodiments of the invention; Fig. 2C is another example of a two-dimensional projection of a safety procedure for a vehicle, according to some embodiments of the invention; Fig. 3A is an illustration of a space-time diagram of a vehicle, according to some embodiments of the invention; Fig. 3B is an exemplary illustration of another space-time diagram of a vehicle, according to some embodiments of the invention; Fig. 3C is an exemplary illustration of another space-time diagram of a vehicle, according to some embodiments of the invention; Fig. 3D is an exemplary illustration of another space-time diagram of a vehicle, according to some embodiments of the invention; Fig. 3E is an exemplary illustration of another space-time diagram of a vehicle, according to some embodiments of the invention; Fig. 3F is an example three-dimensional representation of safety procedures for a plurality of vehicles, according to some embodiments of the invention; Fig. 4A is an example of two-dimensional projections of safety procedures for a plurality of vehicles, according to some embodiments of the invention; Fig. 4B is another example of two-dimensional projections of safety procedures for a plurality of vehicles, according to some embodiments of the invention; Fig. 4C is another example of two-dimensional projections of safety procedures for a plurality of vehicles, according to some embodiments of the invention; Fig. 4D is another example of two-dimensional projections of safety procedures for a plurality of vehicles, according to some embodiments of the invention; Fig. 4E is an example of two-dimensional projections of security procedures for a plurality of objects, according to some embodiments of the invention; Fig. 4F is an example of two-dimensional projections of security procedures for a plurality of perceived and non-perceived objects, according to some embodiments of the invention; Fig. 5A is an example of intersection points of two-dimensional projections of safety procedures and corresponding actions for a plurality of vehicles, according to some embodiments of the invention; Fig. 5B is another example of intersection points of two-dimensional projections of safety procedures and corresponding actions for a plurality of vehicles, according to some embodiments of the invention; Fig. 5C is another example of intersection points of two-dimensional projections of safety procedures and corresponding actions for a plurality of vehicles, according to some embodiments of the invention; Fig. 6A is an exemplary illustration of a fault analysis for a vehicle, according to some embodiments of the invention; Fig. 6B is another example of a fault analysis for a vehicle, according to some embodiments of the invention; Fig. 7A is an exemplary illustration of a control curve corresponding to a fault analysis for a vehicle, according to some embodiments of the invention; Fig. 7B is an exemplary illustration of the use of a safety potential for obstacle avoidance, according to some embodiments of the invention; Fig. 8 is a flowchart illustrating a method for obstacle avoidance, according to some embodiments of the invention; Fig. 9A is an exemplary visualization of security procedures, according to some embodiments of the invention; Fig. 9B is another exemplary visualization of safety procedures of first vehicles with respect to a second vehicle, according to some embodiments of the invention; Fig. 9C is another example visualization of projections of first vehicle safety procedures relative to a second vehicle, according to some embodiments of the invention; Fig. 9D is another exemplary visualization of projections of first vehicle safety procedures relative to a second vehicle, according to some embodiments of the invention; Fig. 9E is another exemplary visualization of projections of first vehicle safety procedures relative to a second vehicle, according to some embodiments of the invention; Fig. 10 is a flowchart illustrating a method for trajectory visualization techniques, according to some embodiments of the invention; Fig. 11A is an illustration of an exemplary autonomous vehicle, according to some embodiments of the invention; Fig. 11B shows an example of camera positions and fields of view for the exemplary autonomous vehicle of Fig. 11A is, according to some embodiments of the invention; Fig. 11C is a block diagram of an example system architecture for the example autonomous vehicle of Fig. 11A is, according to some embodiments of the invention; Fig. 11D is a system diagram for communication between (a) cloud-based server(s) and the exemplary autonomous vehicle of Fig. 11A is, according to some embodiments of the invention; and Fig. 12 is a block diagram of an exemplary computing device suitable for use in implementing some embodiments of the invention. DETAILED DESCRIPTION OF THE INVENTION

[0009] Systems and methods are disclosed in connection with the analysis of safety procedures of a vehicle and objects in an environment for obstacle avoidance. The invention may be described with respect to an exemplary autonomous vehicle 102 (alternatively referred to herein as "vehicle 102" or "autonomous vehicle 102"), an example of which is described herein with reference to Fig. 11A-11D. Furthermore, although the invention may be described with respect to an autonomous vehicle system 100, this is not intended to be limiting, and the methods and processes described herein may be implemented on systems including additional or alternative structures, components, and / or architectures without departing from the scope of the invention. Security force field

[0010] The invention relates to at least a portion of a system for safely controlling an autonomous vehicle without the need for human supervision. More specifically, the invention relates to methods and processes for an obstacle avoidance level of an autonomous driving software stack (e.g., in some implementations, the last or lowest level of the autonomous driving software stack before a propulsion layer) used to ensure that a collision between a vehicle and objects in the environment does not occur. In some examples, the obstacle avoidance mechanisms described herein are executed even if their execution involves non-compliance with traffic laws or other road regulations generally followed by a higher level of the autonomous driving software stack (e.g., a planning layer or a control layer).

[0011] As described herein, conventional systems generally analyze sensor information corresponding to what lies in front of or behind the vehicle (e.g., along a vehicle's longitudinal axis) separately and distinctly from the analysis of sensor information corresponding to what lies to the side of the autonomous vehicle (e.g., along a vehicle's transverse axis). As a result of analyzing the vehicle's longitudinal and transverse environments separately, unnecessary constraints on vehicle control may arise and, particularly when used by autonomous vehicles, may prevent autonomous vehicles from performing natural and / or required vehicle maneuvers (e.g., maneuvering into an adjacent lane in slow-moving traffic when another vehicle is to the side of the autonomous vehicle).Furthermore, when analyzing a current path of the vehicle in a current lane, conventional systems may only rely on information about objects in the current lane and may, as a result, be more limited in handling unforeseen conditions outside the current lane (e.g., in adjacent lanes, on the roadside and / or the like, such as fallen trees, occluded objects, etc.).

[0012] Furthermore, in some conventional systems, a safety procedure may be executed when certain scenarios are perceived, regardless of whether safer options exist that are not the safety procedure. In other conventional systems, there may be exceptions to the execution of the safety procedure, which may be specified by rules and moderated by input information, such as a lane structure, path structures based on map information, and / or the like. However, even in these conventional systems that consider exceptions, there may still be a reliance that an exception is available for the scenario perceived by the vehicle, allowing the vehicle to abort the safety procedure and perform another action(s).However, it may be highly unlikely that an exception exists for every scenario, so if an exception is unavailable, the safety procedure may be implemented, even though it produces a less safe outcome. By not separately analyzing the safety of each scenario in the environment to find a known safe measure (e.g., one where a collision is unlikely), these conventional systems may implement the safety procedure or one of its exceptions, even if other, more safe measures are available.

[0013] In contrast to conventional systems, the invention includes a system that can calculate a safety potential (e.g., a measure of a probability or imminent danger of an occurring collision) for a safety procedure, use the safety potential as a basis, and then determine whether a different action or measure or set of actions or measures can be performed to adjust the safety potential to reduce the probability and / or imminent danger (and thus the likelihood, in some scenarios) of a collision.As a result, exceptions and rules, such as those used in conventional systems, are not required because the system evaluates each situation, determines the safety potential for the safety procedure, and then determines whether to implement the safety procedure or one or more measures that exceed the safety potential associated with the safety procedure.

[0014] To achieve this, the current system can determine a state (e.g., a position, a speed, an orientation, a yaw rate, etc.) of a vehicle, vehicle information (e.g., a width, a longitude, etc.), and use the state and the vehicle information to determine points in space and time that the vehicle occupies. The system can then, based on the scenario (type of road, such as a motorway or country road, the speed of the vehicle, the other objects in the environment, etc.), determine a safety procedure for the vehicle (e.g., at high speeds, orientate yourself to a current lane and brake to a complete stop; at low speeds, pull to the side of the road and then brake, etc.), and can create a virtual representation of points in space and time (e.g.,in three dimensions, two dimensions for space and one dimension for time) that the vehicle will take when executing the safety procedure (e.g., one or more vehicle-occupied trajectories). In some examples, the vehicle-occupied trajectory(s) may include a number of possible implementations of the safety procedure (e.g., the trajectory when implementing the most severe braking and avoiding a collision, the trajectory when implementing the least braking while still avoiding a collision, and any trajectories in between where braking is neither the most severe nor the least). As such, reference to a trajectory herein may include more than one trajectory (e.g., trajectories), which may include each of the trajectories associated with different implementations (e.g., profiles) of the safety procedure.In some examples, a union of two or more vehicle-occupied trajectories (e.g., based on two or more implementations of the safety procedure) may be determined, such as using a convex hull of an image of the object or vehicle at each time slice. Each of the points within the vehicle-occupied trajectory(s) may be referred to as a claimed set of points.

[0015] The current system can determine states and safety procedures for each object (perceived and unperceived, static and moving) in the environment. The system can then generate virtual representations of the points in space and time that the objects will occupy when executing their respective safety procedures (e.g., object-occupied trajectories). To determine unperceived objects in the environment, the system can use rules based on reasonable expectations. For example, if an intersection point is occupied in any way, the system can generate an unperceived object as a car moving at a reasonable speed and approaching the intersection point from the occluded direction. As another example, if two cars are parked on the side of the road, the system can generate an unperceived object as a person between the two cars.The system can include the non-perceived objects in the analysis in addition to the perceived objects (e.g. objects identified based on sensor data from the vehicle's sensors).

[0016] The system can then monitor the vehicle-occupied trajectory(s) with respect to the object-occupied trajectories to determine whether an intersection or overlap occurs (in some examples, with a built-in safety margin). Once an intersection is determined to occur, the system can implement a "safety force field" and attempt to "repel" the vehicle from the object(s) by implementing the safety procedure or by implementing another set of controls determined to have an equal or lower probability and / or imminent danger of causing an actual collision between the vehicle and one of the objects.

[0017] When deciding whether to implement the safety procedure or another set of controls, the system may calculate a safety potential associated with the safety procedure (in some examples, the safety potential is a representation of the degree of overlap between the vehicle-occupied trajectory(s) and the object-occupied trajectory(s)—e.g., the area or volume of overlap between the two)—and may use the safety potential as a basis or baseline (e.g., no action taken should increase the probability or imminent danger of a collision compared to the safety procedure). In some examples, the safety potential may be determined using a function such that if no overlap is detected, the function is zero and is high or maximum at the time of a first collision.In such examples, the safety potential may be defined as a measurement of the imminent danger of a collision in addition to, or alternatively, a measurement of a probability of a collision. The system may then perform a perturbation analysis on an initial state of the vehicle (e.g., using the chain rule) to determine whether a different set of controls (e.g., a different action, such as accelerating instead of braking, steering left instead of right, etc.) results in a safety potential that indicates an equal or lower probability of a collision between the vehicle and one of the objects compared to the safety potential when the safety procedure is implemented.

[0018] During the implementation of the safety procedure or other action(s), if it is determined that there is no longer an overlap or intersection between the vehicle-occupied trajectory(s) and the object-occupied trajectories (e.g., the imminent danger and / or the probability of a collision is reduced), the system may cease implementation of the safety procedure or other action(s) and return control to a higher-level layer of the autonomous driving software stack (e.g., a planning and / or a control layer) associated with controlling the vehicle according to normal driving protocols (e.g., obeying traffic laws, following current instructions, etc.). In some examples, the chosen action(s) may depend on what the higher layer of the stack originally planned to implement (e.g.,proposed controls that are representative of a planned trajectory), and the system can select the safest controls and / or safe trajectories closest to the originally planned action(s) (e.g., using one or more metrics).

[0019] With reference to now Fig. 1 is Fig. 1 is a block diagram of an exemplary autonomous vehicle system 100 according to some embodiments of the invention. It should be understood that these and other arrangements described herein are provided as examples only. Other arrangements and elements (e.g., engines, interfaces, functions, sequences, groupings of functions, etc.) may be used in addition to or in place of those illustrated, and some elements may be omitted entirely. Furthermore, many of the elements described herein are functional units that may be implemented as discrete or distributed components or in conjunction with other components, and in any suitable combination and location. Various functions described herein as being performed by entities may be performed by hardware, firmware, and / or software. For example, various functions may be performed by a processor executing instructions stored in memory.

[0020] The autonomous vehicle system 100 may include an example autonomous vehicle 102, one or more servers 104, and / or one or more objects 106. In some examples, one or more of the autonomous vehicle 102, the server(s) 104, and / or the one or more objects 106 may have similar components, features, and / or functions as a computing device 1200 of Fig. 12, which is further described herein. The provisions relating to Fig. 1 described components, features and / or functions of the autonomous vehicle 102 can be implemented using the features, components and / or functions described in more detail in this document with reference to Fig. 11A - 11D. In addition, the methods described with reference to Fig. 1 described components, features and / or functions of the server(s) 104 using the information provided with respect to Fig. 11D, functions, components and / or functions described in more detail must be implemented.

[0021] The autonomous vehicle 102 may include a sensor manager 108. The sensor manager 108 may manage and / or abstract sensor data from sensors of the vehicle 102. For example, and with reference to Fig. 11C, the sensor data may be generated (e.g., continuously, at intervals, based on certain conditions) by sensors of a GNSS (Global Navigation Satellite System) 1158, one or more RADAR sensors 1160, one or more ultrasonic sensors 1162, one or more LIDAR sensors 1164, sensors of an inertial measurement unit (IMU) 1166, one or more microphones 1196, one or more stereo cameras 1168, one or more wide-angle cameras 1170, one or more infrared cameras 1172, one or more surround cameras 1174, one or more long-range and / or medium-range cameras 1198, and / or other sensor types.

[0022] The sensor manager 108 may receive the sensor data from the sensors in different formats (e.g., sensors of the same type, such as LIDAR sensors, may output sensor data in different formats) and may be configured to convert the different formats into a unified format (e.g., for each sensor of the same type). As a result, other components, features, and / or functionality of the autonomous vehicle 102 may use the unified format, thereby simplifying the processing of the sensor data. In some examples, the sensor manager 108 may use a unified format to apply control back to the sensors of the vehicle 102, e.g., to adjust frame rates or perform gain control.The sensor manager 108 may also update sensor packets corresponding to the sensor data with timestamps to support the processing of the sensor data by various components, features, and functionalities of the autonomous vehicle system 100.

[0023] A world model manager 122 may be used to create, update, and / or define a world model. The world model manager 122 may use information generated and received from an obstacle perceiver 110, a path perceiver 112, a wait perceiver 114, and / or a map perceiver 116. For example, the world model may be defined at least in part based on affordances for obstacles, paths, and wait conditions that may be perceived in real-time or near-real-time by the obstacle perceiver 110, the path perceiver 112, the wait perceiver 114, and / or the map perceiver 116. The world model manager 122 may continuously update the world model based on newly generated and / or received inputs (e.g., data) from the obstacle perceiver 110, the path perceiver 112, the wait perceiver 114, the map perceiver 116, and / or other components of the autonomous vehicle system 100.

[0024] The world model may be used to help inform one or more planning components 124 (e.g., associated with a planning layer of an autonomous driving software stack or architecture), one or more control components 126 (e.g., associated with a control layer of the autonomous driving software stack), one or more obstacle avoidance components 128 (e.g., associated with an obstacle or collision avoidance layer of the autonomous driving software stack), and / or one or more drive components 130 (e.g., associated with a drive layer of the autonomous driving software stack).

[0025] The obstacle perceiver 110 may perform obstacle perception or detection, which may be based on where the vehicle 102 is permitted or able to travel and how fast the vehicle 102 can travel without colliding with an obstacle (e.g., an object 106, such as a structure, an entity, a vehicle, etc.) detected by the sensors of the vehicle 102. In some examples, the object(s) 106 may include other vehicles (e.g., cars, trucks, motorcycles, buses, etc.) that may communicate directly and / or indirectly with the vehicle 102. For example, the object(s) 106 may communicate directly with the vehicle 102 via vehicle-to-vehicle communication, such as over one or more network types (e.g., local wireless networks). In other examples, the object(s) 106 may communicate indirectly with the vehicle 102, for example, via the servers 104 and one or more networks (e.g.,via a cellular network). In such examples, the object(s) 106 may communicate with the server(s) 104, and the server(s) 104 may communicate with the vehicle 102, and vice versa. The information received from and / or about the objects 106 may also be used by the path perceiver 112, the map perceiver 116, and / or other components, features, and / or functionality of the vehicle 102.

[0026] The path perceiver 112 may perform path perception, e.g., by perceiving nominal paths available in a particular situation. In some examples, the path perceiver 112 further considers lane changes for path perception. A lane diagram may represent the path or paths available to the vehicle 102 and may be as simple as a single path on a highway entrance ramp. In some examples, the lane diagram may include paths to a desired lane and / or indicate available changes along the highway (or other road type), or may include adjacent lanes, lane changes, forks, curves, cloverleaf intersections, merges, and / or other information.

[0027] The wait perceiver 114 may be responsible for determining restrictions for the vehicle 102 based on rules, conventions, and / or practical considerations. For example, the rules, conventions, and / or practical considerations may be related to traffic lights, multi-way stops, right-of-way, merges, toll plazas, gates, police or other emergency personnel, road workers, stopped buses or other vehicles, one-way bridge arbitrations, ferry docks, etc. In some examples, the wait perceiver 114 may be responsible for determining longitudinal restrictions on the vehicle 102 that require the vehicle to wait or slow down until some condition is met. In some examples, wait conditions result from potential obstacles, such as cross traffic in an intersection, which can be determined by directly detecting, for example, the obstacle perceiver 110 (e.g.,using sensor data from the sensors because the obstacles may be obscured within the sensors' fields of view). As a result, the wait perceiver can provide situational awareness by resolving the threat of obstacles that are not always immediately perceptible through rules and conventions that can be perceived and / or learned. Thus, the wait perceiver 114 can be used to identify potential obstacles and implement one or more controls (e.g., slowing down, stopping, etc.) that might not be possible if one relied solely on the obstacle perceiver 110.

[0028] The map perceiver 116 may include a mechanism by which behaviors are recognized, and in some examples, to determine specific examples of what conventions apply at a particular location. For example, the map perceiver 116 may determine from data representing past trips or travel that there are no U-turns at a particular intersection between certain hours, that an electronic sign indicating lane directionality changes depending on the time of day, that two traffic lights in close proximity (e.g., barely offset from each other) are associated with different streets, that in Rhode Island, the first car waiting to turn left at a traffic light is breaking the law by turning in front of oncoming traffic when the light turns green, and / or determine other information.The map perceiver 116 can inform the vehicle 102 about static or stationary infrastructure objects and obstacles. The map perceiver 116 can also generate information for the wait perceiver 114 and / or the path perceiver 112, for example, to determine which light must be green at an intersection for the vehicle 102 to take a particular path.

[0029] In some examples, information may be sent, transmitted, and / or provided from the map perceiver 116 to the server(s) 104 (e.g., to a map manager 118 of the server(s) 104), and information may be sent, transmitted, and / or provided from the server(s) 104 to the map perceiver 116 and / or a location manager 120 of the vehicle 102. The map manager 118 may include a cloud mapping application located remotely from the vehicle 102 and accessed by the vehicle 102 over a network (e.g., the network(s) 1190 of Fig. 11D). For example, the map perceiver 116 and / or the localization manager 120 of the vehicle 102 may communicate with the map manager 118 and / or one or more other components or functionalities of the server(s) 104 to inform the map perceiver 116 and / or the localization manager 120 about past and current trips or journeys of the vehicle 102, as well as past and current trips or journeys of other vehicles. The map manager 118 may provide mapping outputs (e.g., map data) that may be localized by the localization manager 120 based on a particular position of the vehicle 102, and the localized mapping outputs may be used by the world model manager 122 to generate and / or update the world model.

[0030] The planning component(s) 124, which may be part of a planning layer of the autonomous driving software stack or architecture, may include a route planner, a lane planner, a behavior planner, and a behavior selector, as well as other components, features, and / or functionalities. The route planner may use, among other things, information from the map perceiver 116, the map manager 118, and / or the localization manager 120 to generate a planned path that may consist of GNSS waypoints (e.g., GPS waypoints). The waypoints may be representative of a particular distance into the future of the vehicle 102, such as a number of city blocks, a number of kilometers, a number of meters, a number of miles, etc., which may be used as a target for the lane planner.

[0031] The lane planner may use the lane graph (e.g., the lane graph from the path perceiver 112), object poses within the lane graph (e.g., according to the localization manager 120), and / or a destination point and a direction in the distance into the future from the route planner as inputs. The destination point and direction may be mapped to the best-matching drivable point and direction in the lane graph (e.g., based on a GNSS and / or compass heading). A graph search algorithm may then be executed on the lane graph starting from a current edge in the lane graph to find the shortest path to the destination point.

[0032] The behavior planner may determine the feasibility of basic behaviors of the vehicle 102, such as staying in the lane or changing lanes to the left or right, so that the feasible behaviors can be matched with the most desired behaviors output by the lane planner. For example, if it is determined that the desired behavior is not safe and / or available, a default behavior may be selected instead (e.g., the default behavior may be staying in the lane if a desired behavior or changing lanes is not safe).

[0033] In some examples, in addition to the other inputs of the planning component(s) 124 described herein, the behavior planner may give greater consideration to free-form trajectories by considering a dynamic occupancy grid (e.g., a grid indicating stationary and moving objects in the vicinity of the vehicle 102 as determined by sensors of the vehicle 102 and / or map information). In such examples, the behavior planner may generate a number of different paths (e.g., fanning out from a nominal or desired path for the respective behavior), such as paths that are slightly offset laterally with varying turn-in amounts. The paths may then be compared to the dynamic occupancy grid to check for safety and desirability, including a check for comfort (e.g., for the passenger(s)) and consistency with the nominal path.

[0034] The behavior selector may execute logic based on the output of the behavior planner and the request from the lane planner to determine the behavior to be performed. For example, if the lane planner requires the vehicle 102 to remain in the lane, the behavior selector may keep the vehicle 102 in the current lane. If a lane change is requested by the lane planner, the lane change may be verified against the lane diagram and executed if the behavior planner determines that the lane change is safe and does not require harsh braking (which may be uncomfortable for the passenger(s)), for example. The path through a lane change may be the path produced by the behavior planner if the behavior selector has confirmed that the lane change is appropriate.

[0035] The control component(s) 126 may follow a trajectory or path (lateral and longitudinal) received from the behavior selector of the planning component(s) 124 as closely as possible and within the capabilities of the vehicle 102. The control component(s) 126 may use tight feedback to deal with unplanned events or behaviors that are not modeled and / or anything that causes deviations from the ideal (e.g., an unexpected deceleration). In some examples, the control component(s) 126 may use a forward prediction model that takes the control as an input variable and produces predictions that can be compared to the desired state (e.g., the desired lateral and longitudinal path required by the planning component(s) 124). The control(s) that minimize discrepancies may be determined.In some examples, temporal filtering may be used to reduce oscillations that occur during unmodeled delays (e.g., when no temporal element is used). Some examples may use model predictive control, such as Euler forward integration (or another form of forward integration) of the differential equations modeling the motion of the vehicle 102. In such examples, discrepancies may be measured at multiple points in the future and compensated for by an objective function. In some examples, a proportional-integral-derivative (PID) controller may be used for longitudinal control, with lookup tables based on the relative distance, relative speed, and speed of the vehicle 102. Comfort constraints may be applied to acceleration (e.g.,5 m / s2) and vibration, and / or speed-dependent limits can be set for steering angle and steering angle rate.

[0036] Although the planning component(s) 124 and the control component(s) 126 are depicted separately, this is not intended to be limiting. For example, in some embodiments, the demarcation between the planning component(s) 124 and the control component(s) 126 may not be precisely defined. As such, at least some of the components, features, and / or functionality associated with the planning component(s) 124 may be associated with the control component(s) 126, and vice versa.

[0037] The obstacle avoidance component(s) 128 may assist the autonomous vehicle 102 in avoiding collisions with objects (e.g., moving and stationary objects). The obstacle avoidance component(s) 128 may include a "primal level" obstacle avoidance computation mechanism and serve as a "survival brain" or "reptilian brain" for the vehicle 102. In some examples, the obstacle avoidance component(s) 128 may be used independently of components, features, and / or functions of the vehicle 102 required to obey traffic laws and drive courteously. In such examples, the obstacle avoidance component(s) may ignore traffic laws, rules of the road, and courteous driving norms to ensure that collisions do not occur between the vehicle 102 and any objects.To this extent, the obstacle avoidance layer may be a separate layer from the rules of the road layer, and the obstacle avoidance layer may ensure that the vehicle 102 performs safe actions only from an obstacle avoidance perspective. The rules of the road layer, on the other hand, may ensure that the vehicle complies with traffic laws and conventions and observes legal and conventional rights of way (as described herein).

[0038] Both the obstacle avoidance layer and the road layer rules can include one or more perception components, as well as planning and control components. Core obstacle avoidance perception reliability can be ensured through multiple redundancies, such as cameras, radar sensors, lidar sensors, etc. By separating the obstacle avoidance layer, as done in some examples, independent validation can be achieved to high levels of confidence, providing a foundation for safety. The road layer rules can be validated in a similar way, with ground-truth measurements for perception and right-of-way determination, as well as mathematical correctness validation of the resulting planning.

[0039] With respect to the autonomous vehicle system 100, the vehicle 102 may include at least one safety procedure for obstacle avoidance, and each of the objects 106 may include at least one safety procedure. The obstacle avoidance component(s) 128 may then operate under the assumption that the vehicle 102 and the objects 106 in the environment each include a corresponding safety procedure. The safety procedures for the vehicle 102 and / or the objects 106 may include procedures for straightening or fixing the steering wheel and coming to a complete stop, pulling over to the side of the road and then coming to a complete stop, and / or another safety procedure. Obstacle avoidance according to the invention may be based on an assumption that all actors (e.g.the vehicle 102 and the objects 106) should perform their safety procedures before the trajectory(s) resulting from their safety procedures intersect(s) with that of another actor. With this approach, a collision should not occur unless one of the actors has not done what was required. If a collision occurs, the fault can be clearly determined because at least one of the actors likely did not follow their safety procedure. For example, the actor who did not perform their safety procedure before or during the time the safety procedures overlap may be at fault unless one of the actors who performed their safety procedure was not traveling at a reasonable speed (e.g.depending on the speed limit), in which case the error can be attributed to the actor who was not driving at an appropriate speed.

[0040] One or more trajectories resulting from a safety procedure, as described herein, may be referred to as a safety force field, and when the trajectories (or safety force fields) of two or more actors intersect, the safety force fields may repel each other, and each actor may need to apply its respective safety procedure or another (alternative) procedure that has a lower probability or imminent danger of collision than the safety procedure. For example, an actor should not apply its safety procedure if the safety procedure cannot help minimize the risk of a collision, such as not braking when tailgating. In such examples, the autonomous vehicle system 100 may determine whether the safety procedure is helpful (e.g.,minimizes the risk), and if it is not helpful (at least not as helpful in minimizing risk as another procedure), then another (alternative) procedure can be performed. For example, if the safety procedure for vehicle 102 is to lock the steering and come to a complete stop, but vehicle 102 is tailgated, vehicle 102 can instead turn to the side of the road and come to a complete stop, thereby avoiding the tailgating actor.

[0041] In some examples, such as the example in Fig. 1, the obstacle avoidance component(s) 128 may be located after the control component(s) 126 in an autonomous driving software stack (e.g., to receive desired controls from the control component(s) 126 and to test the controls for obstacle avoidance). However, although the obstacle avoidance component(s) 128 are illustrated (e.g., with respect to an autonomous driving software stack) as stacked atop the planning component(s) 124 and the control component(s) 126, this is not intended to be limiting.For example, depending on the embodiment, the obstacle avoidance component(s) 128 may additionally or alternatively be implemented before the planning component(s) 124 or the control component(s) 126, before the control component(s) 126 but after the planning component(s) 124, as part of or an integral part of the planning component(s) 124 and / or the control component(s) 126, as part of the obstacle perceiver 110, and / or at another part of an autonomous driving software stack or architecture. As such, the obstacle avoidance component(s) 128 may be implemented at one or more locations within an autonomous vehicle driving stack or architecture without departing from the scope of the invention.

[0042] In some examples, as described herein, the obstacle avoidance component(s) 128 may be implemented as a separate, discrete feature of the vehicle 102. For example, the obstacle avoidance component(s) 128 may operate separately (e.g., in parallel with, before and / or after) the planning layer, the control layer, the propulsion layer, and / or other layers of the autonomous driving software stack.

[0043] The obstacle avoidance component(s) 128 may include a state determiner 132, a safety procedure determiner 134, a stress set determiner 136, a trajectory generator 138, a safety potential calculator 140, a control analyzer 142, and / or one or more additional or alternative components. The state determiner 132 may determine a state of the actors (e.g., the vehicle 102 and the objects 106, static or dynamic) in the environment. The state of each actor may generally include a position, a velocity, a direction (e.g., a heading), a speed, one or more accelerations (e.g., scalar, rotational, etc.), and / or other information about the state of the actors. The state may include the position of the actor in two-dimensional space (e.g.,(x, y) coordinates), a unit direction of the actor and / or a scalar velocity of the actor at a time. In some examples, the state may encode or represent additional or alternative information, such as a rotational velocity (e.g., yaw) and / or a scalar acceleration in each direction. For example, a state, X. A , for each actor as an m-dimensional state vector, which is expressed in equation (1) as follows: XA(t)∈ℝm

[0044] As an example, such as when the state X A is a five-dimensional vector (e.g. m = 5), the state vector in equation (2) can be represented as follows: xA=[yτdτv]τ where y is the position of the actor in two-dimensional space, d is a unit direction vector, and v is a scalar velocity.

[0045] For each actor, if the state of the actor is considered as a function of time, a vector can represent a state trajectory, X A , of the actor (e.g., the state trajectory, X A , every state, X A , of the actor at any time within a time span). The state trajectories may be determined for each of the actors by the state determiner 132, and the collection of states (e.g., at any time) and / or the collection of state trajectories (e.g., as a function of time) may include a set of state spaces or state trajectories for all actors in the environment.

[0046] The state determiner 132 may determine the state of the vehicle 102 using any combination of sensors, such as the GNSS sensors 1158, the IMU sensors 1166, the speed sensors 1144, the steering sensors 1140, etc. The state determiner 132 may determine and / or infer the state of the objects 106 in the environment using any combination of the stereo camera(s) 1168, the wide-angle camera(s) 1170, the infrared camera(s) 1172, the surround camera(s) 1174, the long-range and / or medium-range camera(s) 1198, the LIDAR sensor(s) 1164, the RADAR sensor(s) 1160, the microphone(s) 1196, the ultrasonic sensor(s) 1162, and / or other sensors of the vehicle 102. In some examples, the state of the objects 106 (e.g.,when one or more of the objects 106 is another vehicle, or a person using a client device capable of wireless communication) using wireless communication, such as vehicle-to-vehicle communication or device-to-vehicle communication, over one or more networks, such as, but not limited to, the networks described herein.

[0047] In some examples, machine learning models, such as neural networks (e.g., convolutional neural networks), may be used to determine the states of the actors. For example, sensor data from the sensors of the vehicle 102 may be applied to one or more machine learning models to assist the vehicle 102 in determining the state of the objects 106 in the environment. For example, the autonomous vehicle 102 may be configured to quickly and efficiently execute neural networks on processed and / or unprocessed data for a variety of functions. For example, a convolutional neural network may be used for object detection and identification (e.g., using sensor data from the camera(s) of the vehicle 102), a convolutional neural network may be used for distance estimation (e.g.,using the sensor data from the camera(s) of the vehicle 102), a convolutional neural network may be used to detect and identify emergency vehicles (e.g., using sensor data from the microphone(s) of the vehicle 102), a convolutional neural network may be used for facial recognition and identification of the vehicle owner (e.g., using the sensor data from the camera(s) of the vehicle 102), a convolutional neural network may be used to identify and process safety and / or security-related events, and / or other machine learning models may be used. In examples using convolutional neural networks, any type of convolutional neural network may be used, including region-based convolutional neural networks (R-CNNs), fast R-CNNs, and / or other types.

[0048] Once the state of the actors is determined, a control model can be determined for the actors (e.g., by the safety procedure determiner 134). For example, a control model can be represented in equation (3) as follows: dxAdt=f(xA,t,c)

[0049] In this respect, the control model for an actor can be a derivation of the state of the actor, X A , in terms of time, t, and control parameters, c,. The control model can be formulated locally as an explicit differential equation with control parameters, c, that can model user inputs such as steering, braking, and acceleration. For example, in some examples, the control model for an actor can be expressed according to the following equation (4): dxAdt=[vdTvbd⊥Ta]T where v is a scalar velocity, d is a unit direction vector, a is a scalar acceleration magnitude, b is a scalar steering parameter, and d is the normal to d, generated by inverting the coordinates of d and negating the first coordinate. In the example of equation (4), the control parameters can be a, the scalar acceleration magnitude, and b, the scalar control parameter.

[0050] Once the control model is determined, a control policy can be specified (e.g., by the safety procedure determiner 134). For example, the control parameters can be a function of the world state, X W , (or a perception of the world state based on the sensor data generated by the sensors of the vehicle 102) and time, t. In this respect, a control policy can be a function of the joint state space of the world and time in ℝ m(where m is the dimension of the actor's state space) that is smooth and bounded. For example, a control policy can be represented in equation (5) as follows: dxAdt=ƒ(xw,t)

[0051] Once the control policy is determined, a safety procedure can be determined for each actor (e.g., by the safety procedure determiner). For example, as described herein, each actor can be assumed to have a safety procedure, SA. The safety procedure can have one or more associated trajectories that can be initiated from an arbitrary starting state, X A , of the actor. The safety procedure can represent the trajectory(s) of the actor, since the actor transitions determine the state, X A, for an actor state goal (e.g., an end position at which the actor can come to a stop). The actor state goal goal may, in some examples, be determined by analyzing sensor data received from one or more sensors (e.g., of the vehicle 102) to determine positions, orientations, and velocities of objects 106 (or other actors) in the environment. Control parameters (e.g., for steering, braking, acceleration, etc.), as described herein, may then be determined for the actors (e.g., the vehicle 102 and / or the objects 106), and a set of functions for guiding the actor to the actor state goal may be determined.

[0052] The safety procedure may result in one or more trajectories that change smoothly with their starting state (e.g., because the safety procedure may be a continuous deceleration to a standstill). In some examples, a safety procedure, S A , can be represented in equation (6) as follows: SA={dxAdt=f(W,t)} where W represents the properties of the world (or the environment). The safety procedure for an actor may or may not depend on fixed properties of the world, depending on the implementation. For example, the safety procedure may not depend on fixed properties of the world, such as the shape of the road or a map. In such an example, the safety procedure may include freezing a direction vector (e.g., by setting a scalar control parameter, b, to zero) and a complete stop by decelerating using a range of acceleration values ​​[α min ,α'], where α min is the minimum acceleration amount or the negative of a maximum braking amount and α' is a negative value greater than α min is, up to a complete stop. This type of safety procedure, S A , can be represented by the following equation (7): SA={dxAdt=[vdT0 a]T:amin≤a≤a′}

[0053] In any one example, the safety procedure may include braking until a complete stop is achieved. At high speeds, the safety procedure may include, without limitation, aligning with a current lane (or with the direction of travel, such as when the vehicle 102 is in the middle of a lane change) and then coming to a complete stop (and may therefore depend on fixed properties of the world, such as lane markings). For example, and without limitation, at low speeds, the safety procedure may include the vehicle 102 steering itself toward the shoulder of the road while decelerating to a stop (and may thus depend on fixed properties of the world). For example, one or more neural networks (e.g., convolutional neural networks) may be used to identify the shoulder of the road and / or maneuver the vehicle 102 to the shoulder of the road.As another example, an HD map 1122 may be used (e.g., using map perceiver 116, map manager 118, and / or localization manager 120). In such an example, HD map 1122 may be received over one or more networks 1190 and / or embedded in vehicle 102.

[0054] In yet another example, the safety procedure may be modified to ensure a certain level of comfort (e.g., maximum comfort) for the vehicle's passengers (e.g., minimal deceleration or change of direction) while ensuring avoidance of a collision. In such an example, a course, trajectory, and / or control sequence for the vehicle 102 may be determined as the safety procedure that maximizes comfort and / or minimizes force exerted on the passengers while ensuring avoidance of a collision with other objects 106 (e.g., vehicles, entities, structures, etc.).In some examples, such as when a collision is unavoidable or the probability of a collision is above a threshold, the safety procedure may be modified to minimize the risk of harm to passengers in the vehicle and other entities in the event of a collision.

[0055] Examples of security procedures are related to Fig. 2A-2C. With respect to Fig. 2A, for example, a safety procedure 202 may involve an actor 204 (or a shape representing the actor 204) coming to a complete stop while maintaining a low or no lateral rate of change. For example, in an unstructured environment, or when fixed properties of the world are ignored, the safety procedure 202 may involve driving straight ahead and / or continuing along the current control loop (which may or may not include a lateral rate of change) until the actor 204 comes to a complete stop. For example, if the actor is currently steering with a right steering angle, the safety procedure 202 may involve continuing with the steering angle until a complete stop. If the actor is currently steering straight ahead, the safety procedure 202 may involve continuing straight ahead until a complete stop is achieved (e.g., as in Fig. 2A).

[0056] In any example, the safety procedures for any actor may include a safety margin (e.g., in addition to or alternatively to the safety margin described herein with respect to a size of the actor). For example, with respect to safety procedure 202, as time increases in space and time relative to the time associated with a current state of the actor, the safety margin for the safety procedure may increase. For example, with respect to safety procedure 202, a width, W1, of the claimed set of safety procedure 202 may be smaller than a width, W2, of the claimed set of safety procedure 202. In such an example, since width, W1, may correspond to an earlier time, there may be a smaller margin for error compared to the time associated with width W2.As a result, the safety margin may increase over space and time to account for this error.

[0057] As another example, during a lane change from a first lane 208A to a second lane 208B, a safety procedure 206 may include the actor 204 (or the shape representing the actor 204) realigning itself with the road (e.g., aborting the lane change and aligning with the direction of travel, such as parallel to the lane markings 210A, 210B, and / or 210C) and coming to a complete stop. In such an example, the safety procedure may take into account the fixed properties of the world (e.g., the lane markings, the direction of the road, etc.). The safety procedure 206 may be designed to minimize the lateral rate of change (e.g., with respect to the road shape) while still aborting the lane change and realigning the actor 204 with the road.

[0058] As another example, a safety procedure 212 may involve actor 204 (or the shape representing actor 204) following the road shape to accommodate curves in the road and come to a complete stop. For example, if actor 204 is already following the road shape, thus accounting for the fixed properties of the world, safety procedure 212 may involve continuing to follow the road shape (e.g., as defined by lane markings 210D and 210E). Similar to safety procedure 206, safety procedure 212 may also be designed to minimize the lateral rate of change while continuing to follow the road shape.

[0059] Once the safety procedure is determined, the claimed set determiner 136 may determine a claimed set of the vehicle 102 and the objects 106 in the environment. The claimed set for an actor may include an occupied trajectory (e.g., each of the points in space occupied by the actor when following a trajectory) of an actor when the actor executes its safety procedure, S A , starting from the state X A , applies.

[0060] To determine the claimed set, the claimed set determiner 136 may determine an area and / or volume in space occupied by the actor based on its state. For example, the autonomous vehicle system 100 may assume that actors are located in an n-dimensional real space, ℜ n, move, and occupy it. In some examples, the autonomous vehicle system 100 may use two-dimensional space, modeling a top view of the real world, for simplicity. In other examples, the autonomous vehicle system 100 may use three-dimensional space. In any example, to determine the claimed set, the autonomous vehicle system 100 may first determine occupied sets of each actor, which represent a set, or set of points, in the space that the actor occupies depending on its state. The occupied set o A , for an actor can be determined as in equation (8) below: oA(xA)⊆ℝn

[0061] If a point in space is in the occupied set of the actor, it can be determined that the actor occupies the point.

[0062] To determine each of the points in the occupied set, a size (e.g., an actual size of the actor) or a representative size (e.g., a shape around and / or with the actor) of the actor may be determined. In some examples, the size or representative size may include an optional safety margin. With respect to the vehicle 102, the size of the vehicle 102 may be known (e.g., based on calibration information, vehicle information, vehicle make and model, and / or other parameters). With respect to the objects 106 in the environment, the size of the objects 106 may be determined using the sensors and sensor data therefrom (e.g., from the sensor manager 108) and / or one or more machine learning models (e.g., convolutional neural networks). In some examples, to determine the size of the actors (e.g., the vehicle 102 and the objects 106), a shape (e.g., a predefined shape, such asa square, a polygon, a bounding box, a cube, a circle, an oval, an ellipse, etc.) may be adjusted around the actor (e.g., to at least include the actor), and the size of the actor may be determined as the size of the predefined shape (e.g., including a safety margin, in some examples, as described herein). For example, the shape may be a two-dimensional shape (e.g., a rectangle or a circle) that serves as a bounding box that at least partially surrounds the actor. In other examples, the shape may be a three-dimensional shape (e.g., a cube) that serves as a bounding box that at least partially surrounds the actor. In any example, the size of the vehicle may be used by the occupied set determiner 136 to determine the points (e.g., (x, y) coordinates) in space that the actor should consider part of the occupied set, etc. A , occupies.

[0063] In some examples, the size of the actor, and thus the representative shape corresponding to the size of the actor, can be determined such that the size and / or shape completely encloses the actor in at least two dimensions (e.g., lateral and longitudinal). By fully enclosing the actor (with an additional safety margin, in examples), the occupied set, the occupied trajectory, and thus the claimed set may be more likely to more accurately represent the actual points in space that the actor would occupy when executing the safety procedure.

[0064] Once the occupied set is determined, the claimed set determiner 136 can determine the occupied trajectory(s), o A, of each actor. The occupied trajectory(s) may include the set of points in space and time that the actor will occupy over time as a function of its trajectory(s). For example, the occupied trajectory(s) may, o A , as follows in equation (9) below: OA(XA)={(y,t):y∈oA(xA(t)),t∈T}⊆ℝn×T

[0065] The occupied movement path(s) of the actor can be changed when applying the safety procedure S A the claimed sentence C AAll points considered to be within an actor's claimed set are points in space and time that the actor may need to maintain the integrity of its safety procedure. Thus, when multiple actors are considered in the environment, the vehicle 102 may analyze each of the claimed sets of actors to determine if any intersection point occurs between them. If an intersection point occurs, one or more actions may be taken to account for the intersection point (e.g., the safety procedure may be implemented, another action may be implemented, etc., as described herein). The claimed set, C A , can be determined as follows according to equation (10) below: CA(xA)⊆ℝn×T where equation (10) can represent the occupied trajectory(s) of the actor that result(s) when the actor executes its safety procedure starting from the state X A applies. In some examples, as described herein, the claimed set may represent a combination or aggregation of each of the documented trajectories resulting from the application of the actor's safety procedure with different parameters. For example, the safety procedure may be applied with a maximum braking profile, a minimum braking profile, a braking profile between maximum and minimum, a maximum steering profile, a minimum steering profile, a steering profile between maximum and minimum, and / or in other ways. In such examples, the claimed set may include the documented trajectories for any number of different applications (e.g., for each different application) of the safety procedure, combined or aggregated.

[0066] As a first example, the claimed set may represent the safety procedure with a first braking profile for coming to a complete stop faster than a second braking profile, and may represent the safety procedure with the second braking profile for reaching a complete stop more slowly (e.g., compared to the first braking profile) while still avoiding a collision. In such an example, thresholds or limits may be set and / or determined to define the first braking profile (e.g., a defined maximum or upper-bounded braking profile) and the second braking profile (e.g., a defined minimum or lower-bounded braking profile).In such an example, the claimed set may represent each of the points in space and time that the actor, through the applied safety procedure, occupies with the first braking profile, the second braking profile, and the points in space and time occupied by the actor that fall between the first and second braking profiles (e.g., as in . Fig. 3C-3E). Depending on the specific embodiment, the thresholds or limits for generating the claimed set may vary.

[0067] The thresholds or limits may be defined based on, but are not limited to, percentages (e.g., percentages of braking intensity) and / or time (e.g., time to a complete stop, such as based on a current rpm or speed). For example, the first braking profile may include a braking intensity of 95% and the second braking profile may include a braking intensity of 85%. As another example, if the vehicle 102 is traveling at 60 miles per hour (mph), the first braking profile may include stopping within three seconds (e.g., slowing down by an average of 20 mph per second), while the second braking profile may include stopping within four seconds (e.g., slowing down by an average of 15 mph per second). A factor of speed may be used to determine time in some examples.In such examples, the first braking profile may be one second for every ten mph that the vehicle 102 is traveling, based on a current state, X. A , of the vehicle 102, and the second braking profile may be one second for every fifteen mph that the vehicle 102 is traveling, based on a current state, X A , of the vehicle 102. Continuing the previous example of the vehicle 102 traveling at 60 mph, the first braking profile may include stopping within three seconds and the second braking profile may include stopping within four seconds.

[0068] As a further example, the claimed set may represent the safety procedure with a first steering profile (e.g., a defined maximum steering profile) for reaching a lateral position (e.g., roadside, alignment with the road, etc.) faster than with a second steering profile, and may represent the safety procedure with the second steering profile for reaching the lateral position slower than the first steering profile. In such an example, thresholds or limits may be set and / or determined to define the first steering profile (e.g., a defined maximum or upper-bounded steering profile) and the second braking profile or steering profile (e.g., a defined minimum or lower-bounded steering profile).In such an example, the claimed set may represent each of the points in space and time occupied by the actor through the security procedure to which the first steering profile, the second steering profile, and the points in space and time occupied by the actor that fall between the first and second steering profiles are applied. Depending on the embodiment, the thresholds or limits for generating the claimed set may vary.

[0069] Similar to the thresholds or limits for the braking profiles, the steering profiles can also be based on percentages (e.g., percentages of steering angle intensity) and / or time (e.g., time to reach the lateral position).

[0070] As a simplified example of claimed sets, the vehicle 102 may be traveling toward a static object 302 (where the direction of travel is in one dimension in the space-time diagram of Fig. 3A). The vehicle 102, when not executing a safety procedure, may have an occupied trajectory 304 that results in the vehicle 102 colliding with the static object 302 (e.g., the vehicle 102 does not implement a safety procedure but continues traveling at the same speed along the same path until it collides with the object). The static object 302 is fixed along the spatial dimension in the space-time diagram because the static object 302 is not moving. In this example, a bounding polygon may be used to represent the size of the vehicle 102 (e.g., a bounding polygon extending between boundary lines 316A and 316B from the front to the rear of the vehicle 102).

[0071] To address the situation of Fig. 3A, a safety procedure may be implemented, such as braking to a complete stop of the vehicle 102 before the collision with the static object 302. For example, and with respect to Fig. 3B, the trajectory generator 138 can generate the trajectory 306 represented by a corresponding claimed set, as determined by the claimed set determiner 136, corresponding to the safety procedure, and the vehicle 102 can implement the safety procedure at time T1, so that the vehicle 102 stops shortly before colliding with the static object 302. The trajectory generator 138 can persistently project the trajectory 306 (representing, for example, the claimed set of the trajectory of the safety procedure) into space until the trajectory 306 is determined to nearly cross the static object 302 (for example, at time T1), and then the vehicle 102 can implement the safety procedure by applying the brakes with an intensity corresponding to the safety procedure (for example,an intensity that stops the vehicle 102 before colliding with the static object 302, with some margin for error, depending on the embodiment. In some examples, the trajectory 306 may correspond to a second braking profile (e.g., a defined minimum or lower-bounded braking profile).

[0072] As another example, and in relation to Fig. 3C, the trajectory generator 138 may generate trajectories 306 and 308 represented by the corresponding claimed set as determined by the claimed set determiner 136 and corresponding to a safety procedure implemented using two different braking profiles (e.g., the claimed set may include each of the points in space and time occupied by the vehicle 102 if the vehicle 102 were implementing both the first trajectory 306, the second trajectory 308, and / or any trajectory in between). For example, the trajectory 306 may include a first braking profile (e.g., a defined minimum or lower-bounded braking profile) and the trajectory 308 may include a second braking profile (e.g., a defined maximum or upper-bounded braking profile).In this example, the vehicle 102 may implement the safety procedure immediately before the collision of the trajectory 306 with the static object 302 (e.g., at time T1). Thus, the trajectory generator 138 may persistently project the trajectory(s) 306 and / or 308 (as represented by the corresponding claimed set) in space and time until the trajectory 306 (or 308, in some examples) is destined to nearly intersect the static object 302, and then the vehicle 102 may implement the safety procedure by applying the brakes at an intensity corresponding to the selected braking profile for the safety procedure.

[0073] One property of the claimed rate may be that the claimed rate does not increase over time when the safety procedure is applied. To this extent, the minimum (or safety) braking profile and the maximum braking profile for a safety procedure may be defined such that the claimed rate does not increase (although the claimed rate may decrease). To this extent, the claimed rate must not increase at any time or during any phase of the implementation of the safety procedure. Therefore, when the safety procedure is first implemented and at the conclusions of the safety procedure (e.g., during a complete standstill), the claimed rate should remain unchanged.

[0074] In relation to two or more actors, and in relation to Fig. 3D, the trajectory generator 138 may generate trajectories 306 and 308 for the vehicle 102, and may generate trajectories 312 and 314 for the object 106 (which, in this example, may be another vehicle). The trajectories 312 and 314 for the object 106 may be based on a bounding polygon similar to that of the vehicle 102, having a size that extends between the boundary lines 318A and 318B. The trajectory 312 may include a braking profile corresponding to a safety procedure (e.g., similar to trajectory 306 for the vehicle 102) determined for the object 106 (e.g., based on a condition, control model, control policy, type, size, and / or other information of the object 106 as perceived and / or determined by the vehicle 102).Trajectory 314 may include a maximum braking profile corresponding to a more aggressive braking profile for the safety procedure, similar to trajectory 308 of vehicle 102. In any example, the points in space and time occupied by the projection of trajectories 306 and 308 may include the claimed set of vehicle 102, and the points in space and time occupied by the projection of trajectories 312 and 314 may include the claimed set of object 106.

[0075] As a result of the, in the example of Fig. 3D, movement of object 106 toward vehicle 102. As vehicle 102 follows trajectory 304 (e.g., a travel trajectory before an intersection or near an intersection of trajectories 306 and 312) and object 106 follows trajectory 310 (e.g., a travel trajectory before the intersection or near an intersection of trajectories 306 and 312), vehicle 102 and object 106 approach each other. As a result, once trajectories 306 and 312 (and / or 308 and 314) are destined to intersect or are within a threshold distance of crossing (e.g., using a bump function as described herein), vehicle 102 may implement the safety procedure corresponding to trajectory 306, trajectory 308, and / or another trajectory therebetween.In such an example, the goal may be for object 106 to also implement its safety procedure according to trajectory 312, trajectory 314, and / or another trajectory between the two simultaneously or within a time period that allows object 106 to stop before colliding with vehicle 102. As further described herein, if a collision occurs in this example and vehicle 102 has implemented the safety procedure, the failure may be attributed to object 106 because vehicle 102 at least did not contribute to the likelihood or imminent danger of a collision.

[0076] As another example, and in relation to Fig. 3E, since the vehicle 102 is following trajectory 304 (e.g., a travel trajectory before an intersection or near an intersection of trajectories 306 and 314 and / or 312) and the object 106 is following trajectory 310 (e.g., a travel trajectory before an intersection or near an intersection of trajectories 306 and 314 and / or 312), the vehicle 102 and the object 106 may be moving in a similar direction. As a result, once trajectories 306 and 314 (and / or 306 and 312) are destined to intersect or are destined to be within a threshold distance of crossing, the vehicle 102 may implement the safety procedure corresponding to trajectory 306, trajectory 308, and / or another trajectory between the two.In such an example, the goal may be for the object 106 to also implement its safety procedure according to the trajectory 312, the trajectory 314, and / or another trajectory between the two simultaneously or within a time period that allows the object 106 to stop before colliding with the vehicle 102.

[0077] Another example, and in relation to Fig. 3F, the vehicle 102 includes a first object 106A (in this example, e.g., a vehicle), and a second object 106B (in this example, e.g., a vehicle) in an environment 326. In this example, the trajectories may occupy a three-dimensional space (e.g., a volume) in space and time within the environment 326. As such, the trajectories may include a longitudinal distance (e.g., a braking or stopping distance), a lateral change (e.g., a steering change), and / or a vertical space (e.g., from the ground plane to a top surface of a bounding polygon or other shape representative of the occupied set of the actor) occupied by the actors (e.g., the vehicle 102, the first object 106A, and the second object 106B) if the actors were to perform their respective safety procedures. As such, the trajectories may be analyzed as fixed volumes with lengths that increase with increasing speed (e.g.,the faster the actor moves, the longer the trajectory(s) and the corresponding points in space and time contained in the occupied sets), and the actors can be characterized by driving around with these volumes attached to them (e.g., protruding from them) while performing collision analysis on the volumes (e.g., the trajectories) rather than performing collision analysis on their actual shape. As a result, by guaranteeing no collisions in the space-time volumes, a guarantee can be given that no collisions occur in actual space. This can be advantageous because avoiding collisions between actual physical objects in real space requires foresight, as the actors have inertia, and once a physical overlap occurs, it may already be too late.However, in space and time, the volumes or trajectories may be considered frozen once an intersection, overlap, or near intersection or overlap between the volumes is determined in space and time, and because there are both transverse and longitudinal dimensions and a shared geometry between the vehicle 102 and the object(s) 106 may not be allowed, the vehicle 102 may be free of collisions (or at least may not contribute to a probability of collision because other actors are outside the control of the vehicle 102).

[0078] In such an example, the trajectory generator 138 of the vehicle 102 may generate the vehicle-occupied trajectory(s) 320 representative of the safety procedure for the vehicle 102 (in some examples, applied over a range of profiles), the object-occupied trajectory(s) 322 representative of the safety procedure for the first object 106A, and the object-occupied trajectory(s) 324 representative of the safety procedure for the second object 106B. In the illustration of Fig. 3F, there is no overlap or intersection, or proximity to an overlap or intersection, between any of the trajectories 320, 322 and 324. In this respect, Fig. 3F, neither the vehicle 102, nor the first object 106A, nor the second object 106B are implementing their safety procedure. However, if one of the trajectories 320, 322, or 324 overlapped or nearly overlapped with another of the trajectories 320, 322, or 324, the actors involved in the overlap or near overlap would be expected to implement their safety procedure (e.g., the vehicle 102 would implement the safety procedure if it were involved, and would expect the other actor to implement its respective safety procedure to avoid a collision).

[0079] In relation to Fig. 3F, the points in space and time occupied by the projection of the trajectory(s) 320 may include the claimed set of the vehicle 102 when implementing the safety procedure. Similar to that described herein with respect to Fig. 2C-2E, the vehicle-occupied trajectory(s) 320 may include a first braking profile, a second braking profile, a braking profile of a different threshold, and / or a combination thereof. Similarly, the points in space and time occupied by the projection of the object-occupied trajectory(s) 322 may include the claimed set of the first object 106A, and the points in space and time occupied by the projection of the object-occupied trajectory 324 may include the claimed set of the second object 106B.

[0080] In relation to Fig. 4A-4F illustrate Fig. 4A-4F various different safety procedures that may be implemented by different actors, and the trajectories occupied by actors that are associated with these safety procedures (e.g., the trajectories that represent the actors' claimed sets if the actors were to implement their safety procedures). In any one example, an end of one or more actor-occupied trajectories (e.g., a vehicle-occupied trajectory and / or an object-occupied trajectory) may indicate the point in space and time at which the actor comes to a complete stop (such as by a portion 420 of the vehicle-occupied trajectory 402 in Fig. 4C).

[0081] In relation to Fig. 4A, when the vehicle 102 is following an object 106, the vehicle 102 may determine that it is following at an unsafe distance (e.g., because the vehicle-occupied trajectory(s) 402 of the vehicle 102 overlap(s) the object-occupied trajectory(s) 404 of the object 106). In such a scenario, the vehicle 102 may implement its safety procedure and begin to slow down to avoid a collision with the object 106. In some examples, as the vehicle 102 slows down, the length of the vehicle-occupied trajectory(s) 402 may decrease (e.g., because the speed is lower, the time to stop—and thus to execute the safety procedure—would also be shorter), and because the vehicle 102 would move farther away from the object 106 by decelerating, the vehicle-occupied trajectory(s) 402 would ultimately not overlap or intersect with the object-occupied trajectory(s) 404.If the vehicle 102 has not yet come to a complete stop by the time an intersection point no longer exists, the vehicle 102 can abort the safety procedure and return control, for example, to the planning layer or the control layer of the autonomous driving software stack. Thus, the vehicle 102 can implement the safety procedure only when and for as long as the danger exists, and can then abort the safety procedure.

[0082] In relation to Fig. 4B, when the vehicle 102 changes lanes to a lane that includes the object 106, the vehicle 102 may determine that the lane change is unsafe (e.g., because the vehicle-occupied trajectory(s) 402 of the vehicle 102 overlap(s) the object-occupied trajectory(s) 404 of the object 106). In such a scenario, the vehicle 102 may implement its safety procedure and begin to slow down and / or align itself with the road (e.g., abort the lane change, similar to the example of Fig. 2B) to avoid a collision with object 106.

[0083] In relation to Fig. 4C, the vehicle 102 may determine when the vehicle 102 is in a more complicated scenario, such as when a first object 106A is approaching the vehicle 102 and a second object 106B is approaching the vehicle from the side (e.g., at the time shown in Fig. 4C when the intersection is nearby, or at a later time when the intersection is even closer) that the current path is unsafe. In such a scenario, the vehicle 102 may implement its safety procedure and begin to slow down to avoid a collision with objects 106A and / or 106B. In some examples, there may be no way to completely avoid the collision, and the vehicle 102 may instead implement the safety procedure or another measure that can cause the least harm (e.g., reduce the potential for safety) to the passengers of the vehicle 102 and objects 106A and 106B, as described herein.

[0084] In relation to Fig. 4D, and as a further advantage of the invention, if the vehicle 102 attempts to change lanes into slow-moving traffic between a first object 106A and a second object 106B (e.g., if the vehicle 102 cannot actually fit between objects 106A and 106B), the vehicle may be allowed to do so. For example, because the vehicle 102 may be able to move into the lane at a slow speed (e.g., as indicated by the short trajectories 402, 404A, and 404B) without the vehicle-occupied trajectory(s) 402 overlapping any of the trajectories 404A and 404B of the objects 106, the vehicle 102 may proceed with the lane change as long as no overlap is determined. In such an example, the first object 106A may be decelerated to allow the vehicle 102 into the lane, the second object 106B may be accelerated, and / or a combination thereof.However, if at any time during the lane change, object 106A accelerates, object 106B decelerates, and / or a combination thereof occurs, thereby causing an overlap between vehicle-occupied trajectory(s) 402 and object-occupied trajectory(s) 404A and / or 404B, vehicle 102 may implement the safety procedure and abort the lane change.

[0085] In contrast to conventional systems that analyze a vehicle's trajectory in a lateral direction separately from the longitudinal direction (e.g., this would not allow this type of lane change because the first object 106A can be determined to be laterally in the path of the vehicle 102), the current system 100 can allow this type of maneuver (e.g., maneuvers where complete space for the vehicle 102, such as between the first object 106A and the second object 106B, is not always available). In this respect, since the autonomous vehicle system 100 may have determined this worst-case scenario by monitoring the trajectories 402, 404A, and 404B, the vehicle 102 and the objects 106A and 106B are able to implement their pre-collision safety procedures, and the vehicle 102 may be allowed by the autonomous vehicle system 100 to perform the lane change, as in Fig. 4D shown.

[0086] In relation to Fig. 4E illustrates Fig. 4E Examples where objects 106 may be pedestrians, children, animals, motorcycles, cyclists, vehicles, and / or other types of objects 106. Different object types may have different safety procedures. For example, children (e.g., object 106E), adults (e.g., objects 106G, 106F, 106C, 106D), running adults (e.g., object 106G), walking adults (e.g., object 106F), animals (e.g., object 106B), motorcycles (e.g., object 106H), cyclists (e.g., object 106A), and / or other types of objects may have different corresponding safety procedures. Therefore, safety procedure determiner 134 may determine the appropriate safety procedure for each of the objects 106 perceived and / or determined to be present in environment 406. For example, since the movement of people and animals can be irregular (e.g.they can move in any direction and / or change direction quickly), the safety procedures can extend longer along the direction of travel of the person or animal, but also extend to either side and behind the people or animals (e.g., as shown in object-occupied trajectories 408B, 408F, and 408G). As a result, the safety procedure for a pedestrian and / or animal can take into account that the pedestrian and / or animal is running as fast as they can in any direction (e.g., an unwary pedestrian). Even with this approach, the vehicle 102 can behave conservatively, with safety arising from reasonable limits on how fast a pedestrian and / or animal can move.

[0087] In the example of Fig. 4E, the vehicle-occupied trajectory(s) 402 of the vehicle 102 may overlap with the object-occupied trajectories 408F and 408G of the pedestrians. In such an example, the vehicle 102 may be executing its safety procedure, and the pedestrians (e.g., objects 106G and 106F) may be expected to execute their safety procedures (e.g., slowing down or stopping). As such, the vehicle 102 may begin to decelerate (and may possibly, as a modification of the safety procedure, turn right to avoid the pedestrians, as further described herein).Finally, as the vehicle 102 slows down and the objects 106G and 106F slow down, the vehicle-occupied trajectory(s) 402 and the object-occupied trajectories 408G and / or 408F may no longer overlap or intersect, at which time the vehicle 102 may abort the safety procedure and continue along the path the vehicle 102 was traveling prior to implementation of the safety procedure.

[0088] In relation to Fig. 4F illustrates Fig. 4F Examples where portions of the environment 410 may be excluded from the fields of view of the sensors of the vehicle 102. As a result, the vehicle 102 may not be able to accurately perceive all objects (e.g., some objects may be obscured), and thus may not be able to determine the appropriate security procedures of obscured objects. For example, the vehicle 102 may only be able to perceive the environment 410 within the field of view of the sensors, as defined by the area between the lines of view 414A and 414B in Fig. 4F. In such examples, the vehicle 102 may determine unseen actors 418A and 418B (alternatively referred to herein as unsensed actors).

[0089] The invisible actors 418A and 418B may be determined based on rules or logic of certain circumstances and / or variables in the environment 410. For example, in some examples, the vehicle 102 may handle visibility limitations by assuming the worst case. However, this may be impractical for the vehicle 102, such as causing the vehicle 102 to react too conservatively for practical use (e.g., with constant braking or traveling at speeds that are much too low). As a result, in some examples, a reasonableness standard is used.For example, a speed limit may be implemented, such as twice the speed limit, so that vehicle 102 can determine that actors traveling faster than twice the speed limit may be present but are unreasonable, and can therefore disregard them when deciding whether or not to implement the safety procedure, but can acknowledge them when evaluating a failure. The determination of these reasonable unseen actors can be part of a control policy, as further described herein.

[0090] For example, with respect to the invisible actor 418A that may be present behind the building 416, the vehicle 102 may determine that it is reasonable for the invisible actor 418A to be present because there may be a three-way intersection with stop signs, or with a stop light, and the light for the vehicle 102 may be yellow (e.g., if it indicates that another vehicle, the invisible actor 418A, may be entering the intersection from behind the building 416). However, in the same scenario, if the traffic light for the vehicle 102 should be green, it may not be reasonable to assume an invisible actor 418A, or at least an invisible actor with one or more trajectories 412A that extend that far, because any actor emerging from behind the building 416 would have a red light and would stop (or violate traffic laws).

[0091] As another example, with respect to the unseen actor 418B, which may be present behind the object 106D (e.g., a parked vehicle) and in front of the object 106C (e.g., another parked vehicle), the vehicle 102 may determine that it is reasonable for the unseen actor 418B to be present because the unseen actor 418B (e.g., a person, based on reasonable object types that may be between two parked vehicles) may attempt to cross the street or enter one of the vehicles (e.g., objects 106C or 106D).As a result, and because the object-occupied trajectory(s) 412A of the invisible actor 418B crosses or overlaps with the vehicle-occupied trajectory(s) 402 of the vehicle 102, the vehicle 102 may begin to perform its safety procedure by decelerating, at least until the space between the objects 106C and 106D is no longer occluded and the existence of an actual object 106 has been affirmed or denied.

[0092] In some examples, latency, discretization, and / or reaction time may be at least some of the practical constraints of the autonomous vehicle system 100 and actors that can be modeled. The autonomous vehicle system 100 may deal with a limitation of perception, more specifically perception and action, in the sense that when an actor does something, it is necessarily based on a not entirely recent perception (e.g., with a time delay). As a result, when the actor does something, it may be based on the perception of the world at an earlier time. For example, an actor (e.g., a human actor, a manually driven vehicle, or a pedestrian) may have some reaction time (e.g., due to a lack of attention while looking at a phone, reaching for something, etc.) before noticing that a potential collision may occur.In such an example, the autonomous vehicle system 100 may take this reaction time into account. In other examples, an actor, such as a vehicle, may include a latency or delay between receiving a command and the actual occurrence of the actuation. The latency or delay may be known (e.g., after identifying a vehicle type) or perceived (e.g., using one or more neural networks). In such examples, the autonomous vehicle system 100 may take this latency or delay into account. In any example, the shape (e.g., the length, width, height, etc.) of the trajectory(s) of the claimed sets for the actors (e.g., the vehicle 102 and / or the objects 106) may be adjusted (e.g., lengthened, widened, etc.) to account for latency, delay, or reaction time.

[0093] In some examples, the magnitude of the latency may be assumed to be Δt. To account for Δt, in some examples, a form of worst-case forwarding prediction may be used, such that a forwarded sentence ϕ A (χ A ,Δt), of actor A by a time interval, Δt, is the set of all states that actor A could possibly reach at the time interval Δt, after being in the state, χ A , is located. The forwarded set of a collection, Θ, of agents at a time interval, Δt,, can be the union of the forwarded sets of all agents Θ, as represented by equation (11) below: Φ(Θ,Δt)=UA∈ΘΦA(xA,Δt)

[0094] An actor may typically have a better ability to predict its own state than that of other actors. In particular, in the control system (e.g., the control component(s) 126) of the vehicle 102, the actual command sequence previously sent may be known, providing a way to predict where the actor itself will be when the actuation command (e.g., delivered to the actuation component(s) 130) that is now accepted is actually issued. For practical purposes, this may allow the forwarded set to include only one point, effectively resulting in deterministic forwarding and, moreover, resulting in a single actor state. In general, the forwarding mechanism may be non-deterministic forwarding and may result in a series of states.While in some examples a non-deterministic forwarding of the actor itself may be used, and may require that the control policy is safe for all possible states of the actor, in other examples, in order to reduce complexity, a deterministic forwarding of the actor itself may be assumed.

[0095] A result may be a control policy for the forwarded actor, implicitly assuming that the state parameterization is updated with a prediction based on all actuation commands in the queue up to the currently discussed actuation command. Under these assumptions, the control command may refer to the actor state under consideration, and the only delay may be information regarding other actors (e.g., objects 106 other than vehicle 102).

[0096] A propagated control policy may be safe at this point in time with respect to wherever the perceived collection of actors has moved, despite the latency constraints between perception and action. This, in turn, may be a direct consequence of the worst-case assumption and the definition of a safe control policy. Since all constraints (e.g., wherever in the environment other actors may go at the time the vehicle 102 is executed) that may exist are assumed to be present, the autonomous vehicle system 100 can thus comply with all relevant constraints.

[0097] Furthermore, the autonomous vehicle system 100 of the invention can combine latency detection with visibility perception and can use this information to avoid entering irrational states. For example, consider the set, ϕ(V,Δt)∪(ϕ(Λ,Δt)∩Ψ), where V, Λ, Ψ are the sets of visible, invisible, and irrational agents, respectively. First, visibility can be considered to provide a complete collection of all agents (visible and invisible, as described herein) in the world to be considered at a given time. Then, latency can be considered in this complete world representation by forwarding the set of agents. Finally, irrational agents can be excluded from the forwarded set of invisible agents.In some examples, irrational actors can be excluded before the propagation, but this would not allow for the inclusion of irrational actors who make it to sane states during the propagation. Even if irrational invisible actors can be excluded, in some examples, irrational visible actors cannot be excluded because removing actually perceived actors may not result in an accurate world state.

[0098] The safety potential calculator 140 can determine a safety potential between two or more actors in an environment. For example, for two actors, actor A and actor B, the combined state space Ω A × Ω B(e.g., the state space of actor A and the state space of actor B) can be compared and an uncertain set can be determined (e.g., the set of points in the combined state space of the two intersecting actors). In this respect, the uncertain set can be the points from the claimed set of actor A, C A , which correspond to the points from the claimed set of actor B, C S In some examples, the uncertain sentence, U AB , can be determined according to the following equation (12): UAB⊆ΩA×ΩB

[0099] The safety potential calculator can then determine a safety potential function on the combined state space of the actors (e.g., actor A and actor B). For example, the safety potential can be a differentiable function of real values ​​in the combined state space, which can be strictly positive on the uncertain set and non-negative elsewhere. The safety potential, if all actors apply arbitrary elements in their safety procedures, must not increase. In some examples, the safety potential, ρ AB , can be determined according to the following equation (13): ρAB:ΩA×ΩB→ℝ

[0100] The safety potential can be exactly zero at a small (e.g., threshold) distance from the unsafe set (e.g., immediately in front of the trajectories representing the actors' claimed sets). A contribution of each actor to a change in the safety potential can be expressed in some examples using the chain rule. For example, the change in the safety potential, ρ AB , based on the contributions of both actors with respect to time according to equation (14): dρABdt=∂ρAB∂xAdxAdt+∂ρAB∂xBdxBdt

[0101] In some examples, the autonomous vehicle system 100 may impose a more stringent requirement, such as requiring that the contribution of each of the individual safety procedures to the change in the safety potential be less than or equal to zero. In such examples, the following equation (15) may be an infinitely differentiable function of real values ​​for the safety potential, ρ AB , represent: ρAB:ΩA×ΩB→ℝ

[0102] In such an example, the safety potential on the combined state space can be strictly positive on the uncertain set and non-negative elsewhere, and the following relations hold for it as shown by equations (16) and (17): ∂ρAB∂xAsB≤0 for arbitrary sA∈SA ∂ρAB∂xBsB≤0 for any sB∈SB

[0103] In some examples, being universally differentiable is not necessarily a prerequisite for a security feature. In such examples, the security feature can be universally differentiable without departing from the scope of the invention.

[0104] A local change to the safety potential of each actor can be the dot product between the control policy and the gradient of the safety potential (e.g., with respect to the actor's state). The control policy can be the negative gradient of the safety potential, subject to limits. The safety force field can be the gradient of the safety potential with respect to the state (e.g., the derivative of the safety potential with respect to the state change). For example, with respect to an actor A and an actor B, the negative gradient, F AB , the safety potential, ρ AB, as shown below in equation (18), can be referred to as the safety force field on actor A from actor B. FAB=−∂ρAB∂xA

[0105] As described herein, the vehicle 102 should behave with respect to each actor in a manner that ensures at least the same level of security as that of its security procedure. A secure control policy for actor A (e.g., the vehicle 102) with respect to each actor B of a set of actors in the environment is a control policy represented by the relationship in equation (19) below: FABdxAdt≥minsA∈SAFABsA

[0106] We can make some reasonable assumptions about the specified safety procedure so that the minimum in equation (19) is always achieved, so to speak, the set is compact. In other words, the relationship of equation (19) states that a safe control policy for vehicle 102, when mapped into the full-state derivative, can have a dot product against the safety force field of any other actor that is at least as large as that of any element of the vehicle 102's safety procedure. In some examples, the control policy can be additive with respect to the safety procedure, and the addition can have a dot product that is at least zero against the other actor's safety force field.

[0107] Two actors, actor A and actor B, with safe control policies with respect to each other, should not collide with each other. For example, if the two actors move along their trajectories with respect to time, the local change in the safety potential can be partitioned into the two contributions from the two actors. If both actors have safe control policies, the two contributions should not be larger than if the optimal or desired elements of the safety procedure of both actors (expressed algebraically, assume that sA*∈SA and sB*∈SB the trajectories are the minima: FABsA*=minsA∈SAFABsA and FBAsB*=minsB∈SBFBAsB reach) would apply at this point (e.g., their contributions should not be greater than zero), as expressed by the following equation (20): dρABdt=∂ρAB∂xAdxAdt+∂ρAB∂xRdxBdt≤∂ρAB∂xAsA*+∂ρAB∂xBsB*≤0

[0108] In equation (20), the first equality is based on the chain rule, the first inequality is based on the definition of a safe control policy, and the last inequality is based on the definition of a safety potential. Because the safety potential can be non-negative and the change in the safety potential can be less than or equal to zero anywhere along the combined trajectories of actor A and actor B, the safety potential must never be zero, which means that the two trajectories should never form an unsafe set, and thus actor A and actor B should not collide.

[0109] In some cases, there may be an overlap or crossover between security procedures of different actors. Fig. Taking 5A-5C, for example, overlap between safety procedures (e.g., actor-occupied trajectories representing claimed sets of actors when the safety procedures are executed) of different actors can occur in a variety of different ways. When overlap occurs, it may indicate that more than one actor is claiming the same share of space and time, so even if all actors are executing their safety procedures, there may still be a problem. The safety force field can be thought of as the contention that takes place between different actors as they attempt to claim equal shares of space and time. Once an overlap or intersection occurs, a constraint can be imposed on the actors.The constraint may be that all actors should contribute to reducing the overlap (and thus the security potential) at least as much as their security procedure would. To this extent, the security procedure can always be an option, and all other actions taken by the actors should only contribute to a net decrease in the security potential compared to the security procedure. Reference to . Fig. Taking Figures 5A-5C, the constraints 506 can be viewed as representing the safety force fields of the vehicle 102 and the objects 106 repelling each other.

[0110] In some examples, and with reference to Fig. 5A, the intersection point between the trajectories occupied by actors (e.g., the trajectories representing the claimed sets of the actors)—such as vehicle-occupied trajectory(s) 502 of vehicle 102 and object-occupied trajectory(s) 504 of object 106—may cause a constraint 506A on object 106 and a constraint 506B on vehicle 102. For example, constraints 506 may represent the safety force field when vehicle 102 and object 106 repel each other. As shown in Fig. 5A, constraints 506 may be due to a limitation of the controls of the vehicle 102 and / or the object 106. For example, an arrow 508A may indicate the controls for the object 106 as a result of constraint 506A. The controls may be braking and / or not turning right, and turning left may be acceptable. Similarly, an arrow 508B may indicate the controls for the vehicle 102 as a result of constraint 506B. The controls may not be turning left, and turning right may be acceptable.

[0111] As a further example, and with reference to Fig. 5B, the intersection point between the trajectories occupied by actors (where, for example, the trajectories represent the claimed sets of the actors), such as the vehicle-occupied trajectory(s) 502 of the vehicle 102, the object-occupied trajectory(s) 504A of the object 106A, and the object-occupied trajectory(s) 504B of the object 106B, may cause a constraint 506C between the object 106B and the object 106A, a constraint 506D between the object 106A and the object 106B, a constraint 506E between the object 106A and the vehicle 102, and / or a constraint 506F between the vehicle 102 and the object 106A. As in Fig. 5B, constraints 506 may be attributed to a restriction on the control of the vehicle 102 and / or the objects 106. For example, an arrow 508C may indicate the controls for object 106B as a result of constraint 506C. The controls may not be steering right, and turning left and / or braking may be permitted. Similarly, an arrow 508E may indicate the controls for object 106A as a result of constraint 506D, and an arrow 508D may indicate the controls for object 106A as a result of constraint 506E. The controls for object 106A, as a result of both vehicle 102 and object 106B, may be braking and road following (e.g., the steering control may be offset from arrows 506D and 506E so that the remainder is no steering control and only braking).An arrow 508F may indicate the controls for the vehicle 102 as a result of the constraint 506F. The controls may not be to steer left, and a turn right may be acceptable.

[0112] As a further example, and with reference to Fig. 5C, the intersection point between the trajectories occupied by actors (e.g., the trajectories representing the claimed sets of the actors), such as the vehicle-occupied trajectory(s) 502 of the vehicle 102, the object-occupied trajectory(s) 504C of the object 106C, the object-occupied trajectory(s) 504D of the object 106D, and the object-occupied trajectory(s) 504E of the object 106E, a constraint 506H between the object 106D and the vehicle 102, a constraint 506I between the vehicle 102 and the object 106D, a constraint 506J between the object 106E and the vehicle 102, a constraint 506K between the vehicle 102 and the object 106E, a restriction 506L between the object 106C and the vehicle 102, a restriction 506M between the vehicle and the object 106C and the object 106B, and / or a restriction 506E between the object 106A and the vehicle 102. As in Fig. 5C, constraint 506 may be attributed to a constraint on the controls of the vehicle 102 and / or the objects 106. For example, an arrow 508G may indicate the controls for object 106C as a result of constraint 506L. The controls may not be right or left steering and braking. Similarly, an arrow 508H may indicate the controls for object 106D as a result of constraint 506H. The controls may not be right or left steering and braking. An arrow 508I may indicate the controls for object 106E as a result of constraint 506J. The controls for object 106E may not be left or right steering and braking. Arrows 508J, 508K, and 508L may indicate the controls for the vehicle 102 as a result of the constraints 506M, 506K, and 506I.The controls for the vehicle 102 may be braking and not turning right, although turning left may be acceptable.

[0113] When the constraints 506 are determined, an earliest intersection point between (a) vehicle-occupied trajectory(s) (e.g., of actor A) and (a) object-occupied trajectory(s) (e.g., of object B) can be determined. This can, in some examples, be determined by searching space and time (e.g., ℝ ℜ × T) for an earliest crossing point, p (e.g., between circles, bounding boxes, or other shape(s) used for the trajectory(s) (e.g., representing a projection of the claimed set of safety procedures in space and time)), and then performing a differential analysis for the crossing point, p. In such examples, the safety potential, ρ AB, can be represented according to the following equation (21):) ρAB=‖tAstop−pt,tBStop−pt‖k where p t the time coordinate for the crossing point, p, and t Astop : and t Bstop are the stopping times for actors A and B, respectively, when they apply their safety procedure, assuming that their safety procedure sets are singletons. Note that the k-norm in this definition of the safety potential can be replaced by any norm where k≥1, including the max-norm. Furthermore, the derivative (e.g., the derivative of p with respect to the vehicle's state) can also be calculated.

[0114] The safety procedure, considered as one or more trajectories of the actor's state, can be represented by points γ(t) of the actor in the world and rotations R(t) from the actor to the world in the actor's occupancy set definition. For example, assume that a point, z, in the actor's coordinate system moves to a world point, w(t) (e.g., a point in world space), as a function of time, when the safety procedure is executed, as represented by the following equation (22): w(t)=[y(t)+R(t)zt]

[0115] The differential analysis of the world points, w, with respect to the change in the state of the agent, χ A, can provide an understanding of how the surface of the trajectory(s) moves in space and time due to a change in the state of the actor. Primarily, the shape of the surface does not change in space and time because the shape of the surface can depend on second derivatives. Thus, if the local shape of the space-time surface of the trajectory(s) (e.g., representing the safety procedure) is known for an actor (e.g., either a surface normal or a vertex tangent), and the derivative of the world points, w, with respect to the change in the state of the actor χ A, this is all the information that may be needed to perform a differential analysis of how the surface behaves. Consequently, this information can be used to determine the change in the intersection point. For example, a change in the world point, w(t), can be related to the change in the agent's state, χ A , according to the following equations (23) and (24), where equation (24) can represent a more specific version of equation (23) if y(t) and R(t) are defined using equations (25)-(29): ∂w∂xA=∂y∂xA+∂R∂xAz ∂w∂xA=[Is(t)I+[zz⊥]td000] xA=[ydv]with y∈ℝ2,d∈ℝ2,v∈ℝ SA={[vd0amin]} s(t)=vt+amint22 y(t)=y+s(t)d R(t)=[dd⊥]

[0116] The earliest crossing point can be a crossing point between two smooth surfaces, between a vertex of the trajectory(s) of actor A and a smooth surface of the trajectory(s) of actor B, or between a vertex of the trajectory(s) of actor B and a smooth surface of the trajectory(s) of actor A. In an example where the earliest crossing point, p, occurs between two smooth surfaces (e.g., the surfaces swept by two circles moving over time), the local surface at this crossing point can be approximated to a first approximation by a plane (e.g., in space and time).The plane can be found by calculating the derivative of the change in the world points, w, with respect to time, t, at the crossing point, p, and taking the cross product with a direction vector for a tangent vector to the smooth or polygonal shape at the same point (which can be found for a polygon by transforming its endpoints using y(t), R(t) and subtracting them). Assume the presence of such vectors on the local plane of both surfaces, with respect to both actors. Further, assume that the vectors have been normalized to unit size, so that the result is A⊥, K⊥. Then it can be observed that the local motion of the A-surface is given by the derivative of the change in the world points, w, with respect to the change in the state of the actor, χ. A , is measured. A correction of the A surface to return to the B surface can then be a multiple, q, of (l−A⊥A⊥⊤)B⊥ The sum of the two can result in the following vector of equation (30): ∂p∂xA=(1−A⊥A⊥⊤)B⊥q+∂w∂xA

[0117] Using the following restriction of the following equation (31): B⊥⊤∂p∂xA=0 can allow solving for q as in equation (32) below: q=−B⊥⊤∂w∂xAL−(A⊥⊤B⊥)2 which then: ∂p∂xA=∂w∂xA+((A⊥⊤B⊥)A⊥−B⊥)1−(A⊥⊤B⊥)R(B⊥⊤∂w∂xA) can result.

[0118] In an example where the earliest crossing point, p, lies between a curve swept by a vertex of the A-surface and a smooth part of the B-surface, a tangent vector A⊥ (represented in equation (34) below) to the curve and a normal vector to the space-time B-surface can be assumed. AT=dwAdt / |dwAdt|

[0119] It can further be assumed that the vectors are normalized to unit size. A similar calculation can be performed with respect to the smooth-smooth case described herein. The local motion of the A-curve can be determined by the derivative of the change in the world points, w, with respect to the change in the state of the actor, χ A , can be measured. The correction along the A curve to get back to the B surface can then be a multiple, q, of A⊥. The sum of the two can be the vector, as shown in equation (35) below: ∂p∂xA=ATq+∂w∂xA

[0120] Using the following restriction of the following equation (36): B⊥⊤∂p∂xA=0 can allow solving for q as in equation (37) below: q=−B⊥⊤∂w∂xAA⊤⊤B⊥ which then: ∂p∂x=∂w∂xA−ATA−B⊥(B⊥T∂w∂xA) can result.

[0121] In an example where the earliest crossing point, p, lies between a smooth part of the A-surface and the curve swept by a vertex of the B-surface, it can be assumed that there is a normal vector to the space-time A-surface and a tangent vector, B⊥, (represented in equation (39) below), to the curve. BT=dwBdt / |dwBdt|

[0122] Furthermore, it can be assumed that the vectors are normalized to unit size. The local motion of the A-surface can be described by the derivative of the change in the world points, w, with respect to the change in the state of the agent, χ A , can be measured. The movement of the crossing point, p, along the B curve can be represented by the equation (40) below: δpδxA=BTq which can be a multiple, q, of B⊥. The subtraction of these two can occur in the plane of the A-surface and thus perpendicular to A⊥, which can lead to the equations (41) and (42) below: A⊥T(BTq−∂w∂xA)=0 q=A⊥T∂w∂xAA⊥TBT which then: ∂p∂xA=DTA⊥TBT(A⊥T∂w∂xA) can result.

[0123] In some examples, to determine the various control options to be used (e.g., control options that contribute to reducing the safety potential), the control analyzer 142 may analyze control options (or control actions) to determine the control option to be implemented. For example, the control component(s) 126 may issue one or more controls to the obstacle avoidance component(s) 128, and the safety potential calculator 140 may determine that the control(s) do not fall within the control policy (e.g., the control(s) do not contribute to the safety potential by reducing the safety potential with respect to the safety procedure). In such examples, the control analyzer 142 may analyze the control(s) from the control component(s) 126 and determine another control(s) that is / are within one or more allowable controls (e.g.,Controls that reduce the safety potential with respect to the safety procedure, or at least are not a net increase in the safety potential. In some examples, the control analyzer 142 may select the control(s) that are closest to the controls from the control component(s) 126 (e.g., the desired controls) that also satisfy the requirement that the control(s) contribute to reducing or balancing the safety potential.

[0124] To achieve this, the control analyzer 142 may perform a disturbance analysis. The disturbance analysis may use the current state of the actors and consider various controls with respect to the current state and how the various controls may contribute to changing the security potential. For example, given the constraints 506, as in Fig. 5A-5C, the control analyzer may determine controls appropriate for the vehicle 102 (and / or the objects 106) that reduce the safety potential of the vehicle 102 (and / or the objects 106). For example, and with reference to Fig. 6A, the vehicle 102 may perform a fault analysis if it is determined that the object-occupied trajectory(s) 604A intersect(s) or overlap(s) the vehicle-occupied trajectory(s) 602B (e.g., according to the safety procedure). The vehicle 102 may analyze any number of possible controls, which may be different from the controls for the safety procedure. For example, although only a limited number of controls and resulting vehicle-occupied trajectories are described and / or illustrated herein, this is intended to be limiting. For example, the fault analysis may consider any number of possible controls and resulting vehicle-occupied trajectories when determining desired and / or acceptable controls.

[0125] As one example, the vehicle 102 may analyze the controls associated with one or more vehicle-occupied trajectories 602A. The vehicle-occupied trajectory(s) 602A may be permitted because they involve a left turn (e.g., away from the object 106) and a deceleration (e.g., as indicated by the shorter length of the vehicle-occupied trajectory(s) 602A relative to the vehicle-occupied trajectory(s) 602B). The vehicle 102 may further analyze the controls associated with the vehicle-occupied trajectory(s) 602C. The vehicle-occupied trajectory(s) 602C may not be permitted because they involve a right turn (e.g., toward the object 106), which may increase the safety potential related to the safety procedure.

[0126] As a further example, and with reference to Fig. 6B, the vehicle 102 may perform a fault analysis if it is determined that the object-occupied trajectory(s) 604B intersect(s) or overlap(s) the vehicle-occupied trajectory(s) 602E (e.g., according to the safety procedure). The vehicle 102 may analyze any number of possible controls, which may be different from the controls for the safety procedure. For example, the vehicle 102 may analyze the controls associated with one or more vehicle-occupied trajectories 602D. The vehicle-occupied trajectory(s) 602D may be permitted because they involve a left turn (e.g., away from the object 106) and a deceleration (such as the shorter length of the vehicle-occupied trajectory(s) 602D relative to the vehicle-occupied trajectory(s) 602E).The vehicle 102 may further analyze the controls associated with the vehicle-occupied trajectory(s) 602F. The vehicle-occupied trajectory(s) 602F may not be permitted because they involve a right turn (e.g., toward the object 106), which may increase the safety potential related to the safety procedure.

[0127] In some examples, variants of non-negative intersections between the safety procedures of two actors (e.g., Actor A and Actor B) can be used to construct safety potentials. Since both safety procedures are applied, the trajectories of the two actors can be implemented, meaning that an intersection operates on the same claimed sets, or whatever remains of them, as the actors progress through the claimed sets. As what remains of the claimed sets decreases, typical intersections cannot grow larger. Thus, if the autonomous vehicle system 100 is able to obtain smooth measurements of the intersection point, the autonomous vehicle system 100 can calculate a safety potential.

[0128] In some examples, the autonomous vehicle system can cover 100 sets with a smooth function and smooth functions that are not infinitely differentiable. For example, covering functions can be generated with bump functions that are infinitely differentiable with compact support following a variety of techniques. In such an example, a function can be smoothed by convolving it with such a bump function following any of the various techniques, and the function can then be referred to as a mollifier.

[0129] In examples, the following relation may be true, according to which for every ∈ > 0 and every ball in ℝ N'for any N, there can be an infinitely differentiable scalar function that is strictly positive inside the sphere, zero at the boundary of the sphere, and zero outside the sphere. For example, the following equation (44) can represent a function, h(x), for a sphere centered at p: h(x)={e12−|(x−p) / ε|2,|(x−p) / ε|<10,otherwise where equation (44) is a shift and a scaling of the function, h(x), of the following equation (45): h(x)={e12−|x|2,|x|<10,otherwise , which is a known impact function. The function can be translated and scaled to center on any point in space, and can have any radius.

[0130] In some examples, the following relation may also be true, according to which for every ∈ > 0 and every sentence in ℝ N' for every N there can be an infinitely differentiable scalar function that covers the set (e.g., the claimed set) and evaluates to zero for every point farther than ∈ from all points in the set. For a bounded set, it may be straightforward to form such a function using impact functions of diameter less than ∈. For example, a bounding sphere for the set can first be determined, and then a finite cover of this bounding sphere can be determined by impact functions with a fixed diameter less than ∈. Then, the addition of every impact function that includes at least one point in the set can be done. This function can clearly cover the set and also be infinitely differentiable, since the function is a finite sum of infinitely differentiable functions.The function can also be zero, since otherwise a spherical function would involve both a point in the set and a point ∈ or further from the set, which would be a contradiction. For an unbounded set, the definition of the function can be extended to include an expanding sequence of spheres, in which new impact functions can be added to cover the additional set between one bounding sphere and the next. This may entail a sequence of impact functions, and the function can be defined as the (now infinite sequence) sum of impact functions. The function may still be well-defined and infinitely differentiable at any time, since for an ∈-neighborhood of a point there can be only a finite set of impact functions from the sequence affecting it.Furthermore, the function can also cover any point in the set and, as a result of the analysis, evaluate to zero for any point falling back into the finite case, ∈ away from the set.

[0131] In some examples, the time interval between the first time there is a crossing point between only slightly thinned occupied sets (e.g., in time slices of the claimed set) and the first time both actors are completely halted, which may be zero if there is no crossing, may be used. This function may be bounded, non-negative, and strictly positive on the uncertain set. The function may also remain constant zero if there is no crossing point, may remain constant up to the crossing point if there is one, and may decrease after the crossing point if there is one. Therefore, the smoothness of the function may be the last thing to ensure, which may already be the case if there is a crossing point and may be the case if there is none.In transition just when the crossing point appears, this can be handled by using a monotonic function of the time interval that flattens the space near zero, as a shock function does at its boundaries.

[0132] In other examples, the dot product between two smooth functions (e.g., which can be computed according to the collision functions and / or molifiers as described herein) that cover the claimed sets of actors can be used. For example, if the initial covering functions on the claimed sets are nearly constant, this can result in a smoothed version of the volume of overlap between the covering functions. Smooth covering schemes (e.g., h A (C A (x A )), h B (C B (x B))) for each of the claimed sets can then be determined. The output or results (e.g., the security potential with respect to the two actors) can then be expressed according to the following equation (46): ρAB(xA,xB)=∫ΩA×ΩB×ThA(CA(xA))hB(CB(xB))dxAdxBdt where the integration can be assumed to take place from the current time until the first time both agents are completely stopped. The resulting function can therefore be smooth, bounded, nonnegative, and strictly positive on the uncertain set.

[0133] For example, and with reference to Fig. 7A, the safety potential can be made smooth to ensure that the safety potential rejects crossing points before the crossing points occur. This can be achieved using a smooth but tight bump function (e.g., using the techniques described herein) that can rise (as represented by a bump) before an overlap between two trajectories occurs. For example, the vehicle 102 can have one or more vehicle-occupied trajectories 732 that represent a projection of the claimed set (e.g., the safety force field) of the vehicle 102 in space and time. The object 106 can have one or more object-occupied trajectories 734 that represent a projection of the claimed set (e.g., the safety force field) of the object 106 in space and time. The vehicle 102 and the object 106 can approach each other (e.g., similar to that of Fig. 3D, as described herein). One or more bump functions may be used for the vehicle 102 and / or for the object 106 to create a raised area 736 (or bump) for the vehicle-occupied trajectory(s) of the vehicle 102 and a raised area 738 (or bump) for the object-occupied trajectory(s) of the object 106. As a result, the raised areas 736 and 738 may be used to reject intersection points before intersection points occur (e.g., because the raised areas 736 and 738 may serve as a buffer for the trajectories 732 and 734). The overlap area 740 in Fig. 7A can increase the security potential in the scenario of Fig. 7A (e.g., where the vehicle 102 and the object 106 approach each other and their trajectories 732 and 734 overlap). In such a situation, once the elevated areas 736 and 738 begin to overlap, which may be before the trajectories 732 and 734 overlap, the safety procedure and / or one or more other control options, as further described herein, may be executed. Consequently, in some examples, the bump functions may be used to discard (e.g., deflect) intersection points of the trajectories 732 and 734 even before the intersection points occur.

[0134] By considering how different controls affect the change in safety potential (e.g., via the states of the actors), the safety potential can be determined for each different control option. The chain rule, as described herein, illustrates how the safety potential cannot increase as long as both the vehicle 102 and the other actor(s) are always as good as their respective safety procedures at decreasing the safety potential. For a vehicle where the controls involve a lateral change (e.g., steering left or right) or a longitudinal change (e.g., acceleration or deceleration), a control image can be used to visualize acceptable control options as a result of a safe driving policy (e.g., one where the safety potential is never increased relative to the safety potential of the safety procedure).

[0135] For example, and with reference to Fig. 7B, a control image 706 (or control restriction image 706) may be representative of acceptable control options 708, unacceptable control options 710, and / or safety procedure control options 712 associated with the safety procedure (which may be included in the acceptable control options 708, as described herein). The control image 706 may be a binary image such that pixels associated with the acceptable control options 708 are represented by a first color, pixels associated with the unacceptable control options 710 are represented by a second color, and in some examples, pixels associated with the safety procedure control options 712 may be represented as a third color (although in other examples, the safety procedure control options 712 may be represented as the acceptable control options 708 in the first color).The x-axis of the control image 706 may correspond to a lateral control of the vehicle (e.g., turning left, driving straight, or turning right) and may be represented by a steering angle. The y-axis of the control image 706 may correspond to the longitudinal control (e.g., braking, deceleration, or acceleration).

[0136] In some examples, such as when a single profile (e.g., a braking profile, a steering profile, etc., as described herein) defines the safety procedure and thus the claimed set, the safety procedure control options 712 may be represented by a single pixel at any time. However, in other examples, such as the Fig. 7B, in which multiple profiles (e.g., braking profiles, steering profiles, etc., as described herein) define the safety procedure and thus the claimed set, the safety procedure control options 712 may be represented by any number of pixels at any time.

[0137] The vehicle 102 and the object 106 in Fig. 7B can be connected to the vehicle 102 and the object 106 in Fig. 6B (e.g., the object 106 may merge into the vehicle 102 such that at least a portion of their respective trajectories overlap). The control image 706 of Fig. 7B may be representative of the control options for the vehicle 102 when the object 106 steers into or transitions into the vehicle 102 such that at least one of the vehicle-occupied trajectories 702 of the vehicle 102 intersects with at least one of the object-occupied trajectories 704 of the object 106 (e.g., as shown in Fig. 6B). The vehicle-occupied trajectories 702A, 702B, and 702C may be the result of different controllers determined by fault analysis, and the acceptable control options 708, the unacceptable control options 710, and the safety procedure control options 712 of the control image 706 may be updated based on the fault analysis. The object-occupied trajectories 704A, 704B, and 704C may be the result of different control determined by fault analysis by the object 106, and the object 106 may, in some examples, generate and / or use its own control image.

[0138] In any example, the acceptable control options 708 may be control options that have an equal or lesser safety potential than the safety procedure control options 712. For example, the vehicle 102 may implement the safety procedure control options 712 and / or implement control options (e.g., the acceptable control options 708) that have an equal or lesser safety potential than the safety procedure control options 712. For example, if the safety potential associated with the safety procedure is zero (e.g., indicating that no collision will occur), then each of the acceptable control options 708 and / or the safety procedure control options 712 may have an associated safety potential of zero. As another example, if the safety potential associated with the safety procedure is greater than zero (e.g.,indicating that a collision may occur), each of the acceptable control options 708 and / or the safety procedure control options 712 may have an associated safety potential that is equal to or less than the safety potential associated with the safety procedure (e.g., acceptable control options 708 may include control options where the safety potential is greater than zero, such as in the case of inevitability).

[0139] As in Fig. However, as illustrated in Figure 7B, even if a safety potential is greater than zero (e.g., indicating that a collision may occur), a disturbance analysis (e.g., using the chain rule) of the vehicle 102 may be used to determine the acceptable control options 708. As described herein, the chain rule may link the control of the vehicle 102 to the change in the state of the vehicle 102 over time, and in turn, the change in the state of the vehicle 102 may be linked to the change in the safety potential.

[0140] In some examples, such as when a desired control for the vehicle 102 (e.g., from the control component(s) 126 of the vehicle 102) may result in a safety potential greater than zero, a fault analysis may be performed to update the control image 706 and determine an acceptable control option 718 (e.g., a control option where the safety potential is zero) that is as close as possible to the desired control option (e.g., within reasonable limits, such as considering a safety margin). Assuming, for example, that the desired control option, with respect to Fig. 7B, was to turn right and slow down (e.g., as represented by the unacceptable control option 710 at point or pixel 714 of the control image 706), the control option determined based on the interference analysis and / or based on one or more rules for finding acceptable control options 708 that are within a threshold relationship (e.g., proximity on the control image 706) to the desired control options may be to stay straight ahead and slow down (e.g., as represented by the acceptable control option 708 at point or pixel 716 of the control image 706).

[0141] In some examples, the threshold relationship may be the acceptable control option 708 that is actually closest to the desired control option (e.g., if the point or pixel 716 would be on or nearly on the boundary 718 between the acceptable control options 708 and the unacceptable control options 710, such as the point or pixel 720). In other examples, such as in Fig. 7B, the threshold relationship may be an acceptable control option 708 closest to the desired control option, taking into account one or more additional criteria. For example, a safety margin may be used such that the point or pixel representing the acceptable control option 708 closest to the desired control option has at least an additional distance within the control image 706 (e.g., this may be with respect to Fig. 7B may include an additional turn to the left or an additional braking). As another example, the safety procedure control options 712 may be taken into account, so that the selected acceptable control option 708 may be weighted toward the safety procedure control options 712 (e.g., as indicated by the point or pixel 722 of Fig. 7B).

[0142] In any example and as described herein, each of the actors (e.g., the vehicle 102 and the object 106 of Fig. 7B) can be expected to contribute to reducing the safety potential when the safety potential is greater than zero (e.g., indicating that a collision may be likely and / or imminent). Within this principle, the idea is that each actor should be at least as good as its respective safety procedure. A cost function 724 of Fig. 7B illustrates the contribution of the vehicle 102 and the object 106 to reducing the safety potential 726 (e.g., driving down the safety potential, as illustrated by an arrow 728) with respect to the cost function 724. The arrow 728 may represent the contribution of the vehicle 102 to reducing the safety potential 726 when the vehicle 102 implements controls (e.g., the acceptable control options 708), in addition to the contribution of the object 106 to reducing the safety potential 726 when the object 106 implements corresponding controls (not shown), which are preferably also acceptable control options (although other actors are outside the control of the vehicle 102 and may therefore be unpredictable).

[0143] As described herein, a quantification of whether and how much each actor contributes to increasing or decreasing the safety potential can be determined with respect to each other (e.g., for fault detection). As a result, when a collision occurs, a fault can be attributed to one or more actors. Typically, an actor can be determined to have behaved badly relative to another actor if the actor contributes to increasing the safety potential relative to another actor. For two actors to collide, at least one of the actors must have contributed to increasing the safety potential above zero. This can be clearly visualized because the trajectories of the actors (representing, e.g., the actors' claimed sets) may at least partially overlap, thus creating an unsafe set.A fault interval, as used herein, can be the uninterrupted time interval before a collision between actor A and actor B, where the safety potential, ρ. AB , is strictly positive. Using the error interval, the error can be attributed to actor A, for example, if actor A is in an unreasonable state (e.g., x A ∈ φ). Actor A may also be at fault if actor A misbehaved with respect to actor B at any time during the fault interval, provided actor B was in a sane state. An actor implementing a safe control policy as described herein cannot be at fault for a collision because an actor with a safe control policy cannot be in an unreasonable state as long as they operate within the safe control policy.

[0144] Another consideration of the current system 100 is yielding and right-of-way. Yielding and right-of-way can be handled by another layer separate from the obstacle avoidance layer (e.g., above). The autonomous vehicle system 100 can operate under the belief that right-of-way is being granted, not taken. If the safety force field (e.g., the trajectories representing the claimed sets of two or more actors) indicates that a constraint due to basic obstacle avoidance exists, each of the actors must respond without exceptions or limitations. If another actor does not yield right-of-way, the vehicle 102 cannot attempt to take the right-of-way.

[0145] This stems from both common sense and the desire for a separation of safety layers. For example, in terms of common sense, if one is about to impact someone who has already clearly not yielded, one would rather brake very hard to minimize damage than insist on one's right of way. As another example related to the separation of safety layers, it may be preferable to have no basic obstacle avoidance safety in a critical situation that is at risk of being invalidated based on complex decisions regarding things like right of way, traffic laws, the presence of a solid dividing line and its implications in different jurisdictions, a traffic sign stating "No U-turns on Thursdays between 4 and 6 p.m.", and / or even the state of a traffic light.A collision risk is a collision risk, regardless of who is right, so it may be desirable to have a separately validated system to handle basic obstacle avoidance. This line of thinking may be similar to the desire not to have an emergency braking system that depends on traffic signs, traffic light perception, and / or a map.

[0146] An example scenario might be when an intersection is so congested that vehicles or other objects that entered the intersection while the traffic light was green may become stuck in the intersection, remaining in the path of the crossing traffic that now has a green light. While this may be something that should have been expected, avoiding this scenario is not always easy or feasible in practice. In such examples, the vehicles or other objects must not drive directly towards the vehicles stuck in the intersection. This type of situation can also arise for many other reasons, such as a broken-down vehicle, a preceding collision, construction, or a drunk driver.

[0147] The safety force field alone must not force actors to yield accordingly. For example, it may be possible to obey the safety force field and still not yield correctly according to the rules and conventions of the road. In such an example, a vehicle may enter an intersection and stop, after which the vehicle may comply with the constraints of the safety force field (e.g., since standing still is always permitted). However, this must not prevent the vehicle from delaying or otherwise impeding intersecting traffic and / or violating traffic rules. This example is a necessary result if core obstacle avoidance is to be separated from the long rest of traffic rules. For example, if all traffic rules had to be obeyed by the core obstacle avoidance layer, all rules would be pulled into the obstacle avoidance layer, which, as described herein, can be highly undesirable.

[0148] A vehicle that does not yield must not cause a safety force field constraint that occurs in cross traffic in a case where the vehicle should not yield based on traffic rules. This leads to an exemplary definition of yielding. Yielding can, in a sense, be a yielding of the right-of-way, since other actors cannot take away the right-of-way. Yielding to another actor can consist of behaving in such a way that no constraint is induced for that actor and making it clear to that actor, by providing sufficient reserve, that the vehicle will not induce a constraint.

[0149] For example, a vehicle may cross an intersection with crossing traffic or make an unprotected left turn, provided the vehicle, such as one with a large reserve, has not triggered a safety force field restriction on another actor. However, if the vehicle does not have a sufficiently large reserve when moving first, the vehicle may have to stay behind and wait until a sufficiently clear reserve or gap has formed, preventing the vehicle from crossing or causing oncoming traffic to worry that the vehicle might not yield.

[0150] Right-of-way may be the determination of who should yield. Determining right-of-way may, in some examples, require the full extent of wait perception (traffic lights, traffic signs, stop lines, yield lines), such as by wait perceiver 114. Right-of-way may include analyzing who stopped first at a multi-stop junction, who is approaching from the right, understanding rules that vary by country and region, and / or recognizing situations where the rules apply. In some examples, map information may also be used in addition to, or alternatively from, training data, which can provide such rules and allow the vehicle to understand local rules and conventions as accurately as a local.

[0151] Yield can be more difficult to navigate as precisely as obstacle avoidance. For example, if the vehicle is required to yield during a left turn into a T-intersection with cross traffic, the vehicle should not constrain cross traffic. However, after the turn, the vehicle may encounter a stopped vehicle and thus cause the following traffic to ultimately experience a constraint due to the vehicle present there. At some point in this process, the vehicle's responsibility for yielding becomes common sense in that if there is a vehicle ahead, it is the responsibility of other traffic to slow down. The safety force field can clearly prevent the vehicle 102 from performing a dangerous maneuver (e.g.,to enter traffic when another vehicle or object is present), but yielding within the scope of the invention can go a step further and even avoid restricting other traffic.

[0152] The autonomous vehicle system 100 may contain some uncertainties and errors in some situations. To handle uncertainties, confidence intervals may be provided for all metrics required to calculate the constraints of the safety force field (e.g., the trajectory(s) representing the claimed set), such as the shape, position (including distance), velocity, and / or acceleration. These calculations may be performed at the edge of the confidence intervals (e.g., after dilating the shape and distance to the closest point and the velocity to the highest point toward the vehicle 102). Errors (e.g., false detections, non-detections, cases outside the confidence intervals, or misclassification of the actor type), on the other hand, may be handled by redundant perception systems.The very latest form of fusion, for example, may involve calculating the safety force field constraints for each of two or more redundant perception systems (e.g., three redundant perception systems) and allowing the execution of the control options accepted by the majority of perception systems.

[0153] Now on Fig. 8, each block of a method 800 described herein includes a computational process that may be performed using any combination of hardware, firmware, and / or software. For example, various functions may be performed by a processor executing instructions stored in a memory. The methods may also be embodied as computer-usable instructions stored on computer storage media. The methods may be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in for another product, to name a few. Furthermore, the method 800 is exemplary for the autonomous vehicle system 100 of Fig. 1. However, these methods may additionally or alternatively be performed by any system or combination of systems, including, but not limited to, those described herein.

[0154] Fig. 8 is a flowchart illustrating a method 800 for obstacle avoidance according to some embodiments of the invention. The method 800 includes, at block B802, determining a currently claimed set of points. For example, the claimed set determiner 136 may determine a currently claimed set of points occupied by the vehicle 102. To determine the currently claimed set of points, a state of the vehicle 102 may be determined by the state determiner 132.

[0155] Method 800 includes generating one or more vehicle-occupied trajectories at block B804. For example, trajectory generator 138 may generate one or more vehicle-occupied trajectories. To generate the vehicle-occupied trajectories, a safety procedure may be determined by safety procedure determiner 134 (e.g., considering the current environment, speed, objects 106, etc.).

[0156] The method 800 includes, at block B806, detecting an intersection or intersection point between the vehicle-occupied trajectory(s) and an object-occupied trajectory(s). For example, the safety potential calculator 140 may determine an intersection point between the vehicle-occupied trajectory(s) and an object-occupied trajectory(s) of an object 106 in the environment. The method 800 includes, at block B808, calculating a safety potential. For example, the safety potential calculator 140 may calculate the safety potential representing the intersection.

[0157] The method 800 includes, at block B810, executing a safety procedure or an alternative method. For example, the vehicle 102 may implement the safety procedure or an alternative method. As described herein, in some examples, the safety procedure may always be a permissible option (e.g., within the permissible control options). However, in some examples (e.g., based on a failure analysis), a safety potential associated with a method other than the safety procedure may be representative of a lower calculated collision probability between the vehicle and the object. In such examples, the control analyzer 142 may analyze control options associated with alternative methods and determine to allow execution of the controls associated with the alternative methods. Visualization

[0158] To visualize the vehicle-occupied trajectory and the object-occupied trajectory, the trajectories can be rendered or displayed relative to each other on a display. However, viewing the trajectories on a 2D screen in this way, without any adjustments or transformations, can make it difficult to understand the possible intersection points of the object-occupied trajectories with the vehicle-occupied trajectory (e.g., the trajectories may begin to merge and overlap, even if there is no actual overlap in 3D space-time, indicating a collision).

[0159] To account for this, the invention includes visualization techniques that generate graphical representations that may be easier to understand and to visualize the object-occupied trajectories (e.g., the movement of the objects in space and time) with respect to the vehicle-occupied trajectory. To this end, the system may determine, for each time slice (e.g., for each time segment used by the system or for each discrete time step), a change in the position and orientation of the vehicle with respect to a first time slice (e.g., the current time). The system may then apply a transformation (e.g., an affine transformation) as a function of the change in location and orientation to the vehicle-occupied trajectory for each time slice after the first time slice in order to visually compensate for the change in the vehicle-occupied trajectory over time (at least along the movement axis).The system may further apply the same transformation, based on the change in the position and orientation of the vehicle, to the object-occupied trajectories for each time slice after the first time slice in order to represent the object-occupied trajectories with respect to the now (essentially) static vehicle-occupied trajectory.

[0160] As a result, the vehicle may appear stationary, while the objects appear to be moving relative to the vehicle. In one example, when the vehicle approaches a slower object in front of it, the object may appear in the visualization as if it is moving in the direction of the vehicle. As a result, the object appears to be moving backward (although it is actually moving forward) because the object's speed is less than the vehicle's speed. As another example, when the vehicle turns left toward a straight-moving (e.g., not turning) object, the object may appear in the visualization to be moving in the direction of the vehicle (although the vehicle is actually moving in the direction of the object). Using these processes, intersection points between the vehicle-occupied trajectories and the object-occupied trajectories can be visualized more clearly (e.g.,The future space around the vehicle can be visualized more clearly, creating a more useful visualization for accuracy testing, system evaluations, and / or the like. In some examples, the visualization can be projected into images or videos captured by one or more of the vehicle's cameras (e.g., projected within the images).

[0161] Now on Fig. 9A, illustrates Fig. 9A depicts representations of the vehicle 102 (e.g., as polygons or as a collection of line segments) and two objects, object 106A and object 106B (e.g., as polygons or as a collection of line segments), when the vehicle 102 and objects 106A and 106B implement their respective safety procedures over each of a plurality of time slices 902. As such, the representations may be of the claimed sets of the vehicle 102, object 106A, and object 106B as the actors implement their respective safety procedures (e.g., visualizations of the vehicle-occupied trajectory and the object-occupied trajectories).For example, a time slice 902A may correspond to a current time, a time slice 902B may correspond to a time anywhere along the safety procedure, and a time slice 902C may correspond to an end time for at least one of the safety procedures corresponding to the vehicle 102, the object 106A, or the object 106B (e.g., when the vehicle 102, the object 102A, and / or the object 102B come to a complete stop, complete their respective safety procedure, and / or reach their destination, as described herein). In other examples, the time slice 902C may not represent an end time, but may instead represent the last time slice 902 in a defined or predetermined number of time slices 902 to be rendered in the visualization.

[0162] Although the representation of Fig. 9A only includes three actors, this is not intended to be limiting and is merely for clarity. However, in a real environment, such as on a highway, there may be a large number of actors. If more actors are included in the environment, the visualization of Fig. 9A, it may become increasingly difficult, if not unrealistic, to clearly visualize the vehicle-occupied trajectory in relation to the object-occupied trajectories. For example, even if no intersection point or overlap can occur between the vehicle-occupied trajectory and the object-occupied trajectories, it may appear as if an intersection or overlap does exist. However, the goal of the visualizations may be to determine possible future collisions of actors by determining whether their occupied sets overlap, so perceived overlaps, if they are not present, may not be ideal. The visualization in Fig. 9A may refer to an absolute view of the trajectories and, although it may be used in some examples, may not be as preferable as a relative view (described further herein) in a particular environment.

[0163] With reference to Fig. 9B illustrates Fig. 9B depicts representations of the vehicle 102 (e.g., as polygons or a collection of line segments) and two objects, object 106A and object 106B (e.g., as polygons or a collection of line segments), as the vehicle 102 and objects 106A and 106B implement their respective safety procedures over each of a plurality of time slices 902. However, the vehicle 102 may apply a transformation at each time slice 902 to return the vehicle 102 to its original position and / or orientation (e.g., back to its original position at time slice 902A). As such, a different transformation may be applied for each time slice 902 because the vehicle 102 may have moved to a new location and / or be in a new orientation at each time slice 902 within the time slices 902.

[0164] As a result, a transformation may be applied at time slice 902B such that the position and / or orientation of the vehicle 102 at time slice 902B is equal to the position and / or orientation of the vehicle 102 at time slice 902A. However, a different transformation may be applied such that the position and / or orientation of the vehicle at time slice 902C matches the position and / or orientation of the vehicle 102 at time slice 902A (e.g., different values ​​for the position and / or orientation may be required to return the vehicle 102 from its position and / or orientation at time slice 902C (to the position and / or orientation at time slice 902A) compared to returning the vehicle from its position and / or orientation at time slice 902B).

[0165] Once the transformations for the vehicle 102 are determined at each time slice 902, the same transformations can be applied to each of the objects 106 in the environment (e.g., the object 106A and the object 106B in Fig. 9B) to create a visualization of how each of the objects 106 in the environment moves relative to the vehicle 102 (e.g., because the vehicle 102 may be stationary due to the transformations). For example, the transformation determined for the vehicle 102 at time slice 902B may be applied to the object 106A and the object 106B at time slice 902B. This process may continue for each of the time slices 902 and for each of the actors in the environment. By applying the transformation determined for the vehicle 102 to the other actors, the visualization may provide a clearer representation of the overlap between the vehicle-occupied trajectory and the object-occupied trajectories in the environment.

[0166] In some examples, the transformation may be an affine transformation. In such an example, an affine transformation may be applied as a function of time (e.g., to the entire scene or environment) to return the vehicle 102 to its initial location and / or orientation (e.g., at time slice 902A) and to transform, adapt, or distort the other actors based on the transformation to the vehicle 102. The affine transformation may, in some examples, be represented by the following equation (42): ft:ℝ2→ℝ2givenbyft(x)=Atx+bt where At∈ℝ2×2 and bt∈ℝ2

[0167] As a result of applying the transformation to the vehicle 102, the object 106A and the object 106B, the objects 106A and 106B may appear to be moving relative to the vehicle 102. Thus, the visualization of Fig. 9B may be referred to as a relative view. As an example, the object 106B may be moving toward and / or in the same direction as the vehicle 102. As a result, in the absolute view of Fig. 9A, the object 106B is shown as moving in the same direction and / or toward the vehicle 102. In the relative view of Fig. 9B, however, object 106B appears to be moving away from vehicle 102. This may be because, although object 106B is moving in the same or a similar direction as vehicle 102, object 106B is traveling slower than vehicle 102 and is thus moving toward vehicle 102, but at a slower speed than vehicle 102, thereby increasing the space between vehicle 102 and object 106B. As another example, object 106A may be moving in a similar direction and at a similar speed as vehicle 102, and may thus be in the relative view of Fig. 9B appear stationary with respect to the vehicle 102. The relative view of Fig. Figure 9B thus provides a clearer visualization of the vehicle-occupied trajectories and the object-occupied trajectories and facilitates the visual identification of intersection points or overlaps between them.

[0168] The visualization of Fig. 9B includes a three-dimensional visualization of the time slices 902 for each of the actors (e.g., with time as a separate axis). However, this is not intended to be limiting. For example, instead of including each time slice 902 as a separate shape, the trajectories may be a single shape (e.g., a polygon extending through all time slices 902 without interruptions or boundaries), or broken up into multiple time slices 902, and / or based on other criteria. Furthermore, the visualization may alternatively be two-dimensional instead of three-dimensional. In some examples, the different trajectories may have different colors or be represented by different shapes, or each time window 902 or other segment of individual trajectories may have different colors or different shading or resolution (e.g.,the trajectories and / or the different segments of the trajectories can extend further into the future, or vice versa).

[0169] In some examples, e.g. regarding the visualizations of Fig. 9C and Fig. 9D, the trajectories and / or time slices 902 may be back-projected into an image plane of the image(s) generated by the vehicle 102. In such an example, the vehicle-occupied trajectory of the vehicle 102 may not be reproduced in the image(s) because the vehicle 102 is stationary, so the boundary of the vehicle 102 may not move or obstruct anything. The trajectories may be projected two-dimensionally or three-dimensionally.

[0170] For example, in Fig. 9C an object 106C and an object 106D, which may be located in front of the vehicle 102 (and in the visualization of Fig. 9A and Fig. 9B are not shown), their respective object-occupied trajectories within the image of Fig. 9C. The object-occupied trajectories move relative to the vehicle 102, because they may have resulted from the transformations described above, thereby enabling easier visualization of the object-occupied trajectories with respect to the vehicle. For example, the object-occupied trajectory of object 106C may indicate that the object 106C is moving at substantially the same speed as the vehicle 102, and the object-occupied trajectory for object 106D may indicate that the object 106C is moving at a higher speed than the vehicle. The image may have been captured by a front-mounted sensor on the vehicle 102.

[0171] As a further example, Fig. 9D the object 106C and the object 106D are in front of the vehicle 102, similar to Fig. 9C, as described above, however, object 106D may be decelerating relative to vehicle 102 (or vehicle 102 may be accelerating relative to object 106D). As a result, object 106D may include an object-occupied trajectory extending toward vehicle 102, even though object 106D may be traveling in the same direction as vehicle 102.

[0172] As another example, Fig. 9E the object 106A and the object 106B, which may be located behind the vehicle 102, their respective object-occupied trajectories within the image of Fig. 9E. The object-occupied trajectories move relative to the vehicle 102, because they may have resulted from the transformations described above, thus enabling easier visualization of the object-occupied trajectories relative to the vehicle. The image may have been captured by a rear sensor of the vehicle 102.

[0173] Although a front view and a rear view in Fig. 9C, Fig. 9D and Fig. 9E, respectively, this is not intended to be limiting. For example, similar images may be generated for any of the sensors of the vehicle 102 (e.g., the cameras facing forward, rearward, side, etc.). In some examples, the visualization of the Fig. 9A-9E may be accompanied by a control image, such as the control image 706 of Fig. 7B. In such examples, the control image may illustrate acceptable control options that are consistent with the visualizations of the Fig. 9A-9E can be better understood as a reference.

[0174] In some examples, such as when considering latency, safety margins, reaction time, and / or other factors when generating vehicle-occupied trajectories and / or object-occupied trajectories (e.g., as described herein), multiple potential future trajectories may be considered. For example, due to noise or perceptual delays, there may be a time gap between when the vehicle 102 predicts a collision and when it actually implements a command. Furthermore, at high speeds, additional space between actors may be desired. Further, the object(s) 106 may be allocated a reaction time to implement their own procedures (e.g., safety procedures).As a result, and because any one of the actors may have more than one single path or trajectory, the system may analyze more than one possible trajectory (e.g., all of the same) and include it in the visualization. In such an example, all claimed sets from each of the one or more possible trajectories may be included in an approximation that extends around all of them (e.g., a convex hull or a directional calculation of the surrounding boundary, which may expand over time, e.g., due to a safety margin). In examples where a convex hull is computed, the convex hull may be approximated, for example, by computing and interpolating between extreme selections of control options for the safety procedure (e.g., controls associated with maximum and minimum steering and / or braking).To this extent, the extreme choices of the control options can be calculated, and the remaining control options can be interpolated using the extreme choices.

[0175] As another example, perceived motion may be insufficient to predict future collisions in some scenarios. At high speeds or at intersections, an actor may follow a particular path (e.g., a U-turn, a turning path, a lane following direction, etc.). This information can be learned over time (e.g., using one or more machine learning models such as neural networks). To account for this, in some examples, actors may be assumed to align with a lane structure and then move parallel to it (e.g., based on map information and / or a perception of lane boundaries or a set of known trajectories).Without these assumptions, at high speeds or with an additional lane merging into the current lane, small perceptual errors can escalate into many false collision detections. Using the lane structure as an implicit agreement that cars travel with the direction of the road structure can allow the safety force field to enable reasonable operation of the vehicle 102 in these various scenarios. Even in situations, for example, where an oncoming vehicle is merging lanes and thus its safety force field protrudes into the safety force field of the vehicle 102 during the merge, the lane structure (indicating, for example, that the oncoming vehicle is likely to merge into the other lane and proceed according to the lane structure) can allow the vehicle 102 to proceed unhindered (e.g.without implementing the safety procedure to take into account the oncoming vehicle).

[0176] Now on Fig. 10, each block of the method 1000 described herein includes a computational process that may be performed using any combination of hardware, firmware, and / or software. For example, various functions may be performed by a processor executing instructions stored in memory. The methods may also be computer-usable instructions stored on computer storage media. The methods may be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in for another product, to name a few. Furthermore, the method 1000 is exemplified for the autonomous vehicle system 100 of Fig. 1. However, these methods may additionally or alternatively be performed by any system or combination of systems, including, but not limited to, those described herein.

[0177] Fig. 10 is a flowchart illustrating a method 1000 for trajectory visualization techniques according to some embodiments of the invention. The method 1000 includes, at block B1002, determining a first claimed set of points for a vehicle for each of a plurality of time slices. For example, the claimed set determiner 136 may determine, for each time slice (e.g., time slices 902), a first claimed set of points for the vehicle 102 (e.g., representative of the execution of a safety procedure of the vehicle). The determination of the first claimed set may be based on a position, a velocity, an orientation, and / or other state information of the vehicle at a current time. In some examples, as described herein, the first claimed set may include multiple possible implementations of the safety procedure (e.g., different braking profiles, steering profiles, etc.).

[0178] The method 1000 includes, at block B 1004, determining a second claimed set of points for an object for each of the plurality of time slices. For example, the claimed set determiner 136 may determine a second claimed set of points for the object 106 (e.g., representative of the execution of a safety procedure of the object) for each time slice (e.g., the time slices 902). The determination of the second claimed set may be based on a position, a velocity, an orientation, and / or other state information of the object at a current time. In some examples, as described herein, the second claimed set may include multiple possible implementations of the safety procedure (e.g., different braking profiles, steering profiles, etc.).

[0179] The method 1000 includes, at block B1006, calculating a change in the position and orientation of the vehicle for each of the plurality of time slices. For example, a transformation may be applied to the position and / or orientation of the vehicle 102 at each time slice. The transformation (e.g., an affine transformation) may be applied to return a position and / or orientation associated with each future time slice to the position and / or orientation of the original or current time slice.

[0180] The method 1000 includes, at block B1008, applying an affine transformation to each of the second claimed sets of points as a function of the change in position and orientation of the vehicle. For example, the same transformation applied to the vehicle 102 in block B1008 can be applied to each of the claimed sets of points of the objects. As a result, the determination of the change in position and / or orientation of the vehicle 102 at each time slice can be applied to the objects 106 at each time slice.

[0181] The method 1000 includes generating a visualization at block B1010. For example, a visualization may be generated that may include representations of the object-occupied trajectories with respect to the vehicle-occupied trajectories. In some examples, such as the visualizations of Fig. 9A-9B, the vehicle-occupied trajectory can also be included in the visualization. In other examples, such as the visualizations of Fig. 9C-9D, the vehicle-occupied trajectory must not be included in the visualization.

[0182] Although the visualization techniques are described herein with respect to the vehicle 102 and the objects 106 in the environment (or more generally, with respect to driving), this is not limiting. For example, these techniques can be used for any scene or scenario in which there are moving and / or static objects, and at least one of the objects is distinguishable from at least one other. These visualization techniques can be used, for example, in computer games, robotics, virtual reality, physical simulations, and / or other technology areas. Exemplary Autonomous Vehicle

[0183] Fig. 11A is an illustration of an exemplary autonomous vehicle 102, in accordance with some embodiments of the invention. The autonomous vehicle 102 (alternatively referred to herein as the "vehicle 102") may include a passenger vehicle, such as a car, a truck, a bus, and / or another vehicle that accommodates one or more passengers. Autonomous vehicles are generally described in terms of automation levels defined by the National Highway Traffic Safety Administration (NHTSA), a division of the U.S. Department of Transportation, and the Society of Automotive Engineers (SAE) "Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles" (Standard No. 13016-201806, published June 15, 2018, Standard No. 13016-201609, published September 30, 2016, and prior and future versions of this standard).The vehicle 102 may be capable of functionality consistent with one or more of the autonomous driving levels 3-5. For example, depending on the embodiment, the vehicle 102 may be capable of conditional automation (Level 3), high automation (Level 4), and / or full automation (Level 5).

[0184] The vehicle 1102 may include components such as a chassis, a vehicle body, wheels (e.g., 2, 4, 6, 8, 18, etc.), tires, axles, and other components of a vehicle. The vehicle 102 may include a propulsion system 1150, such as an internal combustion engine, a hybrid electric power plant, an all-electric motor, and / or another type of propulsion system. The propulsion system 1150 may be connected to a drivetrain of the vehicle 102, which may include a transmission to enable propulsion of the vehicle 102. The propulsion system 1150 may be controlled in response to receiving signals from the throttle / accelerator pedal 1152.

[0185] A steering system 1154, which may include a steering wheel, may be used to steer the vehicle 102 (e.g., along a desired path or route) when the propulsion system 1150 is operating (e.g., when the vehicle is moving). The steering system 1154 may receive signals from a steering actuator 1156. The steering wheel may be optional for full automation functionality (Level 5).

[0186] The brake sensor system 1146 may be used to apply the vehicle brakes in response to receiving signals from the brake actuators 1148 and / or brake sensors.

[0187] One or more controller(s) 1136 that control one or more system-on-chip (SoCs) 1104 ( Fig. 11C) and / or GPU(s), may provide signals (e.g., representative of commands) to one or more components and / or systems of the vehicle 102. For example, the controller(s) may send signals to apply the vehicle brakes via one or more brake actuators 1148, to apply the steering system 1154 via one or more steering actuators 1156, to apply the propulsion system 1150 via one or more throttle / accelerator pedals 1152. The controller(s) 1136 may include one or more built-in (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals and issue operational commands (e.g., signals representing commands) to enable autonomous driving and / or to assist a human driver in driving the vehicle 102.The controller(s) 1136 may include a first controller 1136 for autonomous driving functions, a second controller 1136 for functional safety functions, a third controller 1136 for artificial intelligence functionality (e.g., computer vision), a fourth controller 1136 for infotainment functionality, a fifth controller 1136 for emergency redundancy, and / or other controllers. In some examples, a single controller 1136 may perform two or more of the aforementioned functionalities, two or more controllers 1136 may perform a single functionality, and / or any combination thereof.

[0188] The controller(s) 1136 may provide the signals to control one or more components and / or systems of the vehicle 102 in response to sensor data received from one or more sensors (e.g., sensor inputs). The sensor data may be obtained, for example and without limitation, from one or more of global navigation satellite system sensor(s) 1158 (e.g., Global Positioning System sensor(s)), RADAR sensor(s) 1160, ultrasonic sensor(s) 1162, LIDAR sensor(s) 1164, inertial measurement unit (IMU) sensor(s) 1166 (e.g., accelerometer(s), gyroscope(s), magnetic compass(es), magnetometer(s), etc.), microphone(s) 1196, stereo camera(s) 1168, wide-view camera(s) 1170 (e.g., fisheye cameras), infrared camera(s) 1172, surround camera(s) 1174 (e.g., 360-degree cameras), long-range and / or mid-range camera(s) 1198, velocity sensor(s) 1144 (e.g.,for measuring the speed of the vehicle 102), vibration sensor(s) 1142, steering sensor(s) 1140, brake sensor(s) (e.g., as part of the brake sensor system 1146), and / or other sensor types.

[0189] One or more of the controller(s) 1136 may receive inputs (e.g., represented by input data) from an instrument cluster 1132 of the vehicle 102 and provide outputs (e.g., represented by output data, display data, etc.) via a human-machine interface (HMI) 1134, an audible annunciator, a speaker, and / or via other components of the vehicle 102. The outputs may include information such as a vehicle speed, a velocity, a time, map data (e.g., the HD map 1122 of Fig. 11C), position data (e.g., the position of the vehicle 102, such as on a map), a direction, a position of other vehicles (e.g., an occupancy grid), information about objects and the status of objects as perceived by the controller(s) 1136, etc. For example, the HMI display 1134 may display information about the presence of one or more objects (e.g., a road sign, a warning sign, a traffic light change, etc.) and / or information about maneuvers the vehicle has performed, is currently performing, or will perform (e.g., change lanes now, take exit 34B in two miles, etc.).

[0190] The vehicle 102 further includes a network interface 1124, which may use one or more wireless antennas 1126 and / or modems to communicate over one or more networks. For example, the network interface 1124 may be capable of communication over LTE, WCDMA, UMTS, GSM, CDMA2000, etc. The wireless antenna(s) 1126 may also enable communication between objects in the environment (e.g., vehicles, mobile devices, etc.) using local area networks such as Bluetooth, Bluetooth LE, Z-Wave, ZigBee, etc., and / or low-power long-area networks (LPWANs) such as LoRaWAN, SigFox, etc.

[0191] Fig. 11B is an example of camera positions and fields of view for the example autonomous vehicle 102 of Fig. 11A, according to some embodiments of the invention. The cameras and respective fields of view are an example embodiment and are not intended to be limiting. For example, additional and / or alternative cameras may be integrated, and / or the cameras may be located at various positions on the vehicle 102.

[0192] The camera types for the cameras may include, but are not limited to, digital cameras adapted for use with the components and / or systems of the vehicle 102. The camera(s) may operate at Automotive Safety Integrity Level (ASIL) B and / or another ASIL. The camera(s) may be capable of any image capture rate, such as 60 frames per second (fps), 1120 fps, 240 fps, etc., depending on the embodiment. The cameras may use rolling shutters, global shutters, another type of shutter, or a combination thereof.In some examples, the color filter array may include a Red Clear Clear Clear (RCCC) color filter array, a Red Clear Clear Blue (RCCB) color filter array, a Red Blue Green Clear (RBGC) color filter array, a Foveon X3 color filter array, a Bayer sensor (RGGB) color filter array, a monochrome sensor color filter array, and / or another type of color filter array. In some embodiments, clear pixel cameras, such as cameras with an RCCC, an RCCB, and / or an RBGC color filter array, may be used to increase light sensitivity.

[0193] In some examples, one or more of the camera(s) may be used to perform advanced driver assistance system (ADAS) functions (e.g., as part of a redundant or fail-safe design). For example, a multifunction mono camera may be installed to provide functions including lane departure warning, traffic sign support, and intelligent headlight control. One or more of the camera(s) (e.g., all cameras) may capture and provide image data (e.g., video) simultaneously.

[0194] One or more of the cameras may be mounted in a mounting arrangement, such as a custom (3D-printed) arrangement, to remove stray light and reflections from the vehicle interior (e.g., reflections from the dashboard reflected in the windshield mirrors) that may impair the camera's image data collection capability. With respect to exterior mirror mounting assemblies, the exterior mirror assemblies may be custom 3D-printed so that the camera mounting plate conforms to the shape of the exterior mirror. In some examples, the camera(s) may be integrated into the exterior mirror. For side-view cameras, the camera(s) may also be integrated into the four pillars at each corner of the cabin.

[0195] Cameras with a field of view that includes portions of the environment in front of the vehicle 102 (e.g., forward-facing cameras) can be used for surround vision to help identify forward paths and obstacles, as well as to help provide information relevant to generating an occupancy grid and / or determining preferred vehicle paths with the assistance of one or more controllers 1136 and / or control SoCs. Forward-facing cameras can be used to perform many of the same ADAS functions as LIDAR, including emergency braking, pedestrian detection, and collision avoidance. Forward-facing cameras can also be used for ADAS functions and systems including Lane Departure Warnings (“LDW”), Autonomous Cruise Control (“ACC”), and / or other functions such as traffic sign recognition.

[0196] A variety of cameras may be used in a forward-facing configuration, including, for example, a monocular camera platform that includes a CMOS (Complementary Metal Oxide Semiconductor) color image sensor. Another example may be at least one wide-angle camera 1170, which may be used to perceive objects that come into view from the periphery (e.g., pedestrians, crossing traffic, or bicycles). Although in Fig. 11B, there may be any number of wide-angle cameras 1170 on the vehicle 102. In addition, one or more long-range cameras 1198 (e.g., a telephoto stereo camera pair) may be used for depth-based object detection, particularly for objects for which a neural network has not yet been trained. The long-range camera(s) 1198 may also be used for object detection and classification, as well as basic object tracking.

[0197] One or more stereo cameras 1168 may also be integrated in a front-facing configuration. The stereo camera(s) 1168 may include an integrated control unit comprising a scalable processing unit that may provide programmable logic (FPGA) and a multi-core microprocessor with an integrated CAN or Ethernet interface on a single chip. Such a unit may be used to create a 3D map of the vehicle's surroundings, including a distance estimate for all points in the image. One or more alternative stereo cameras 1168 may include one or more compact stereo vision sensors that may include two camera lenses (one each on the left and right) and an image processing chip that can measure the distance from the vehicle to the target object and process the generated information (e.g.,Metadata) to activate the autonomous emergency braking and lane departure warning functions. Other types of stereo camera(s) 1168 may be used in addition to or alternatively to those described herein.

[0198] Cameras with a field of view that includes parts of the environment to the side of the vehicle 102 (e.g., side view cameras) can be used for a surround view and provide information used to create and update the occupancy grid and to generate side impact collision warnings. For example, the surround camera(s) 1174 (e.g., four surround cameras 1174, as shown in Fig. 11B) may be positioned on the vehicle 102. The surround camera(s) 1174 may include one or more wide-angle cameras 1170, fisheye cameras, 360-degree cameras, and / or the like. For example, four fisheye cameras may be positioned at the front, rear, and sides of the vehicle. In an alternative arrangement, the vehicle may utilize three surround camera(s) 1174 (e.g., left, right, and rear), and may utilize one or more other cameras (e.g., a forward-facing camera) as a fourth surround camera.

[0199] Cameras with a field of view that includes portions of the environment to the rear of the vehicle 102 (e.g., rearview cameras) can be used for parking assistance, surround view, rear collision warning, and occupancy grid creation and updating. A variety of cameras can be used, including, but not limited to, cameras that are also suitable as forward-facing cameras (e.g., long-range and / or mid-range cameras 1198, stereo cameras 1168), infrared cameras 1172, etc.), as described herein.

[0200] Fig. 11C is a block diagram of an example system architecture for the example autonomous vehicle 102 of Fig. 11A, according to some embodiments of the invention. It should be understood that these and other arrangements described herein are provided as examples only. Other arrangements and elements (e.g., engines, interfaces, functions, sequences, groupings of functions, etc.) may be used in addition to or in place of those shown, and some elements may be omitted entirely. Moreover, many of the elements described herein are functional units that may be implemented as discrete or distributed components or in conjunction with other components, and in any suitable combination and location. Various functions described herein as being performed by units may be performed by hardware, firmware, and / or software. For example, various functions may be performed by a processor executing instructions stored in memory.

[0201] Each of the components, features, and systems of the vehicle 102 in Fig. 11C is illustrated as being connected via a bus 1102. Bus 1102 may include a Controller Area Network (CAN) data interface (alternatively referred to herein as a "CAN bus"). A CAN may be a network within vehicle 102 used to control various features and functionalities of vehicle 102, such as brake application, acceleration, braking, steering, windshield wipers, etc. A CAN bus may be configured to have dozens or even hundreds of nodes, each with its own unique identifier (e.g., a CAN ID). The CAN bus may be read to determine steering wheel angle, vehicle speed, engine speeds per minute (RPM), button positions, and / or other vehicle status indicators. The CAN bus may be ASIL B compliant.

[0202] Although bus 1102 is described herein as a CAN bus, this is not a limitation. For example, FlexRay and / or Ethernet may be used in addition to or alternatively to the CAN bus. Although a single wire is used to represent bus 1102, this is not a limitation. For example, there may be any number of buses 1102, which may include one or more CAN buses, one or more FlexRay buses, one or more Ethernet buses, and / or one or more other types of buses using a different protocol. In some examples, two or more buses 1102 may be used to perform different functions and / or used for redundancy. For example, a first bus 1102 may be used for collision avoidance functionality and a second bus 1102 may be used for actuation control.In each example, each bus 1102 may communicate with each of the components of the vehicle 102, and two or more buses 1102 may communicate with the same components. In some examples, each SoC 1104, each controller 1136, and / or each computer within the vehicle may have access to the same input data (e.g., inputs from sensors of the vehicle 102) and may be connected to a common bus, such as the CAN bus.

[0203] The vehicle 102 may include one or more control devices 1136 as described herein with respect to Fig. 11A. The controller(s) 1136 may be used for a variety of functions. The controller(s) 1136 may be coupled to any of the various other components and systems of the vehicle 102 and may be used to control the vehicle 102, the artificial intelligence of the vehicle 102, the infotainment for the vehicle 102, and / or the like.

[0204] The vehicle 102 may include one or more systems on a chip (SoC) 1104. The SoC 1104 may include CPU(s) 1106, GPU(s) 1108, processor(s) 1110, cache(s) 1112, accelerators 1114, data storage 1116, and / or other components and features not shown. The SoC(s) 1104 may be used to control the vehicle 102 in a variety of platforms and systems. For example, the SoC(s) 1104 may be combined in a system (e.g., the system of the vehicle 102) with an HD card 1122 that may be accessed via a network interface 1124 from one or more servers (e.g., server 104 of Fig. 11D) can receive map refreshes and / or updates.

[0205] The CPU(s) 1106 may include a CPU cluster or CPU complex (alternatively referred to herein as a "CCPLEX"). The CPU(s) 1106 may include multiple cores and / or L2 caches. For example, in some embodiments, the CPU(s) 1106 may include eight cores in a coherent multiprocessor configuration. In some embodiments, the CPU(s) 1106 may include four dual-core clusters, each cluster having a dedicated L2 cache (e.g., a 2 MB L2 cache). The CPU(s) 1106 (e.g., CCPLEX) may be configured to support concurrent cluster operation, allowing any combination of the clusters of the CPU(s) 1106 to be active at any time.

[0206] The CPU(s) 1106 may implement power management capabilities that include one or more of the following features: individual hardware blocks may be automatically clocked when idle to conserve dynamic power; each core clock may be driven when the core is not actively executing instructions due to execution of WFI / WFE instructions; each core cluster may be independently power driven; each core cluster may be independently clock driven when all cores are clock driven or power driven; and / or each core cluster may be independently power driven when all cores are power driven. The CPU(s) 1106 may further implement an advanced power state management algorithm in which allowable power states and expected wake-up times are specified, and the hardware / microcode determines the best power state for the core, cluster, and CCPLEX.The processing cores can support simplified power state entry sequences in software, offloading the work to microcode.

[0207] The GPU(s) 1108 may include an integrated GPU (alternatively referred to herein as an "iGPU"). The GPU(s) 1108 may be programmable and efficient for parallel workloads. The GPU(s) 1108 may, in some examples, utilize an extended Tensor instruction set. The GPU(s) 1108 may include one or more streaming microprocessors, where each streaming microprocessor may include an L1 cache (e.g., an L1 cache with at least 96 KB of memory capacity) and two or more of the streaming microprocessors may share an L2 cache (e.g., an L2 cache with 512 KB of memory capacity). In some embodiments, the GPU(s) 1108 may include at least eight streaming microprocessors. The GPU(s) 1108 may utilize computing application programming interface(s) (API(s)). In addition, the GPU(s) 1108 may utilize one or more parallel computing platforms and / or programming models (e.g., NVIDIA's CUDA).

[0208] The GPU(s) 1108 may be power-optimized for best performance in automotive and embedded use cases. For example, the GPU(s) 1108 may be fabricated on a fin field-effect transistor (FinFET). However, this is not limiting, and the GPU(s) 1108 may be fabricated using other semiconductor manufacturing techniques. Each streaming microprocessor may include a number of mixed-precision processing cores divided into multiple blocks. For example, and not limited to, 64 PF32 cores and 32 PF64 cores may be divided into four processing blocks. In such an example, each processing block can be associated with 16 FP32 cores, 8 FP64 cores, 16 INT32 cores, two NVIDIA TENSOR cores with mixed precision for deep learning matrix arithmetic, an L0 instruction cache, a warp scheduler, a dispatch unit, and / or a 64 KB register file.In addition, streaming microprocessors can include independent parallel integer and floating-point datapaths to provide efficient execution of workloads with a mix of computation and addressing calculations. Streaming microprocessors can include independent thread scheduling functionality to enable finer-grained synchronization and cooperation between parallel threads. Streaming microprocessors can include a combined L1 data cache and shared memory unit to improve performance while simplifying programming.

[0209] The GPU(s) 1108 may include high-bandwidth memory (HBM) and / or a 16 GB HBM2 memory subsystem to provide a maximum memory bandwidth of approximately 900 GB / second in some examples. In some examples, synchronous graphics random access memory (SGRAM), such as double data rate synchronous graphics random access memory Type 5 (GDDR5), may be used in addition to, or alternatively to, the HBM memory.

[0210] The GPU(s) 1108 may include unified memory technology, including access counters, to enable more accurate migration of memory pages to the processor that accesses them most frequently, thereby improving efficiency for memory regions shared between processors. In some examples, Address Translation Services (ATS) support may be used to allow the GPU(s) 1108 to directly access the page tables of the CPU(s) 1106. In such examples, when the memory management unit (MMU) of the GPU(s) 1108 experiences a miss, an address translation request may be sent to the CPU(s) 1106. In response, the CPU(s) 1106 may look up the virtual-to-physical mapping for the address in their page tables and send the translation back to the GPU(s) 1108.Therefore, Unified Memory technology can enable a single unified virtual address space for memory of both the CPU(s) 1106 and the GPU(s) 1108, simplifying the programming and porting of applications to the GPU(s) 1108.

[0211] Additionally, the GPU(s) 1108 may include an access counter that can track the frequency of accesses by the GPU(s) 1108 to the memory of other processors. The access counter can help ensure that memory pages are moved to the physical memory of the processor that accesses the pages most frequently.

[0212] The SoC(s) 1104 may include any number of cache(s) 1112, including those described herein. For example, the cache(s) 1112 may include an L3 cache available to both the CPU(s) 1106 and the GPU(s) 1108 (e.g., connected to both the CPU(s) 1106 and the GPU(s) 1108). The cache(s) 1112 may include a write-back cache that can track the state of lines, such as by using a cache coherence protocol (e.g., MEI, MESI, MSI, etc.). The L3 cache may include 4 MB or more, depending on the embodiment, although smaller cache sizes may be used.

[0213] The SoC(s) 1104 may include one or more accelerators 1114 (e.g., hardware accelerators, software accelerators, or a combination thereof). For example, the SoC(s) 1104 may include a hardware acceleration cluster, which may include optimized hardware accelerators and / or large on-chip memory. The large on-chip memory (e.g., 4 MB SRAM) may enable the hardware acceleration cluster to accelerate neural networks and other computations. The hardware acceleration cluster may be used to supplement the GPU(s) 1108 and offload some of the tasks of the GPU(s) 1108 (e.g., to free up more GPU(s) 1108 cycles for other tasks). As an example, the accelerator(s) 1114 may be used for targeted workloads (e.g., perception, convolutional neural networks (CNNs), etc.) that are stable enough to be suitable for acceleration.The term “CNN” as used herein can include all types of CNNs, including region-based or regional convolutional neural networks (RCNNs) and fast RCNNs (such as those used for object detection).

[0214] The accelerator(s) 1114 (e.g., the hardware acceleration cluster) may include one or more deep learning accelerators (DLAs). The DLA(s) may include one or more tensor processing units (TPUs), which may be configured to provide an additional tens of trillion operations per second for deep learning applications and inferencing. The TPUs may be accelerators configured and optimized to perform image processing functions (e.g., for CNNs, RCNNs, etc.). The DLA(s) may be further optimized for a specific set of neural network types and floating-point operations, as well as for inferencing. The design of the DLA(s) may provide more performance per millimeter than a general-purpose GPU, significantly exceeding the performance of a CPU.The TPU(s) can perform several functions, including a single-instance convolution function that supports, for example, INT8, INT16, and FP16 data types for both features and weights, as well as post-processing functions.

[0215] The DLA(s) can quickly and efficiently execute neural networks, in particular CNNs, on processed or unprocessed data for a variety of functions, including, for example and without limitation: a CNN for object identification and detection using data from camera sensors; a CNN for range estimation using data from camera sensors; a CNN for emergency vehicle detection and identification using data from microphones; a CNN for facial recognition and vehicle owner identification using data from camera sensors; and / or a CNN for safety and / or security events.

[0216] The DLA(s) can perform any function of the GPU(s) 1108, and, for example, by using an inference accelerator, a developer can address either the DLA(s) or the GPU(s) 1108 for any function. For example, the developer can focus on processing CNNs and floating-point operations on the DLA(s) and leave other functions to the GPU(s) 1108 and / or other accelerator(s) 1114.

[0217] The accelerator(s) 1114 (e.g., the hardware acceleration cluster) may include one or more programmable vision accelerators (PVAs), which may alternatively be referred to herein as a computer vision accelerator. The PVA(s) may be designed and configured to accelerate image processing algorithms for Advanced Driver Assistance System (ADAS), autonomous driving, and / or augmented reality (AR) and / or virtual reality (VR) applications. The PVA(s) may provide a balance between performance and flexibility. For example, each of the PVA(s) may include, for example and without limitation, any number of RISC (Reduced Instruction Set Computer) cores, Direct Memory Access (DMA), and / or any number of vector processors.

[0218] The RISC cores may interact with image sensors (e.g., the image sensors of one of the cameras described herein), one or more image signal processors, and / or the like. Each of the RISC cores may include any amount of memory. The RISC cores may use one of several protocols, depending on the embodiment. In some examples, the RISC cores may execute a real-time operating system (RTOS). The RISC cores may be implemented using one or more integrated circuit devices, application-specific integrated circuits (ASICs), and / or memory devices. For example, the RISC cores may include an instruction cache and / or tightly coupled RAM.

[0219] The DMA may enable components of the PVA(s) to access system memory independently of the CPU(s) 1106. The DMA may support any number of features used to provide optimization for the PVA, including, but not limited to, support for multidimensional addressing and / or circular addressing. In some examples, the DMA may support up to six or more dimensions of addressing, which may include block width, block height, block depth, horizontal block increments, vertical block increments, and / or depth increments.

[0220] The vector processors may be programmable processors that can be designed to efficiently and flexibly perform programming for computer vision algorithms and provide signal processing functions. In some examples, the PVA(s) may include a PVA core and two vector processing subsystem partitions. The PVA core may include a processor subsystem, one or more DMA engines (e.g., two DMA engines), and / or other peripherals. The vector processing subsystem may operate as the primary processing engine of the PVA and may include a vector processing unit (VPU), an instruction cache, and / or a vector memory (e.g., VMEM). A VPU core may include a digital signal processor, such as a single instruction multiple data (SIMD) or very long instruction word (VLIW) digital signal processor. The combination of SIMD and VLIW can increase throughput and speed.

[0221] Each of the vector processors may include an instruction cache and may be coupled to dedicated memory. As a result, in some examples, each of the vector processors may be configured to execute independently of the other vector processors. In other examples, the vector processors included in a particular PVA may be configured to use data parallelism. For example, in some embodiments, the plurality of vector processors included in a single PVA may execute the same computer vision algorithm, but on different regions of an image. In other examples, the vector processors included in a particular PVA may concurrently execute different computer vision algorithms on the same image, or even execute different algorithms across sequential images or portions of an image.Among other things, any number of PVAs can be included in the hardware acceleration cluster, and any number of vector processors can be included in each of the PVAs. Furthermore, the PVA(s) can include additional error correction code (ECC) memory to increase overall system security.

[0222] The accelerator(s) 1114 (e.g., the hardware acceleration cluster) may include an on-chip computer vision network and SRAM to provide high-bandwidth, low-latency SRAM to the accelerator(s) 1114. In some examples, the on-chip memory may include at least 4 MB of SRAM, consisting, for example, and without limitation, of eight field-configurable memory blocks accessible by both PVA and DLA. Each pair of memory blocks may include an enhanced Advanced Peripheral Bus (APB) interface, configuration circuitry, a controller, and a multiplexer. Any type of memory may be used. PVA and DLA may access the memory via a backbone that provides PVA and DLA fast access to the memory. The backbone may include an on-chip computer vision network that connects PVA and DLA to the memory (e.g., via the APB).

[0223] The on-chip computer vision network may include an interface that determines that both the PVA and the DLA are providing ready and valid signals before transmitting any control signals / addresses / data. Such an interface may provide separate phases and separate channels for the transmission of control signals / addresses / data, as well as bursty communication for continuous data transmission. This type of interface may conform to ISO 26262 or IEC 61508, although other standards and protocols may be used.

[0224] In some examples, the SoC(s) 1104 may include a real-time ray tracing hardware accelerator, as described in US patent application US 2020 / 0 051 318 A1, filed on August 10, 2018. The real-time ray tracing hardware accelerator may be used to quickly and efficiently determine the positions and extents of objects (e.g., within a world model) to generate real-time visualization simulations for RADAR signal interpretation, sound propagation synthesis and / or analysis, simulation of SONAR systems, simulation of general wave propagation, comparison with LIDAR data for localization and / or other functions, and / or for other applications.

[0225] The accelerator(s) 1114 (e.g., the hardware accelerator cluster) have a wide range of applications for autonomous driving. The PVA can be a programmable vision accelerator that can be used for critical processing stages in ADAS and autonomous vehicles. The capabilities of the PVA are a good complement for algorithmic domains that require predictable processing at low power and low latency. In other words, the PVA performs well in semi-dense or dense regular computing, even on small datasets that require predictable runtimes with low latency and low power. Consequently, in the context of autonomous vehicle platforms, PVAs are designed to execute classical computer vision algorithms because they are efficient at object detection and operate on integer mathematics.

[0226] For example, according to one embodiment of the technology, the PVA is used to perform computer stereo vision. In some examples, a semi-global matching-based algorithm may be used, although this is not limiting. Many Level 3-5 autonomous driving applications require on-the-fly motion estimation / stereo matching (e.g., structure from motion, pedestrian detection, lane detection, etc.). The PVA can perform a computer stereo vision function on inputs from two monocular cameras.

[0227] In some examples, the PVA can be used to perform dense optical flow, such as processing raw radar data (e.g., using a 4D Fast Fourier Transform) to provide processed radar. In other examples, the PVA is used for deep time-of-flight processing, such as processing raw time-of-flight data to provide processed time-of-flight data.

[0228] The DLA can be used to power any type of network to improve control and driving safety, including, for example, a neural network that outputs a confidence measure for each object detection. Such a confidence value can be interpreted as a probability or as providing a relative "weight" to each detection compared to other detections. This confidence value allows the system to make further decisions regarding which detections should be considered true positives rather than false positives. For example, the system can set a confidence threshold and consider only detections exceeding the threshold as true positives.In an automatic emergency braking (AEB) system, false positive detections would cause the vehicle to automatically perform emergency braking, which is obviously undesirable. Therefore, only the most trustworthy detections should be considered as triggers for AEB. The DLA may run a neural network to regress the confidence value. The neural network may use at least a subset of parameters as its input, such as bounding box dimensions, a ground truth estimate (e.g., from another subsystem), an output from the inertial measurement unit (IMU) sensor 1166 correlated with the orientation of the vehicle 102, a range and 3D position estimates of the object obtained from the neural network and / or other sensors (e.g., LIDAR sensor(s) 1164 or RADAR sensor(s) 1160), among others.

[0229] The SoC(s) 1104 may include data storage 1116 (e.g., memory). The data storage 1116 may be on-chip memory of the SoC(s) 1104, which may store neural networks to be executed on the GPU and / or the DLA. In some examples, the data storage 1116 may be large enough to store multiple neural network instances for redundancy and security. The data storage 1112 may include L2 or L3 cache(s) 1112. Reference to the data storage 1116 may include a reference to the memory associated with the PVA, DLA, and / or one or more other accelerators 1114, as described herein.

[0230] The SoC(s) 1104 may include one or more processor(s) 1110 (e.g., embedded processors). The processor(s) 1110 may include a boot and power management processor, which may be a dedicated processor and subsystem to perform boot power and management functions and associated security enforcement. The boot and power management processor may be part of the SoC(s) 1104 boot sequence and provide power management services at runtime. The boot power and management processor may provide clock and voltage programming, support for system transitions to low power, management of thermal and temperature sensors of the SoC(s) 1104, and / or management of the power states of the SoC(s) 1104.Each temperature sensor may be implemented as a ring oscillator whose output frequency is proportional to the temperature, and the SoC(s) 1104 may use the ring oscillators to sense temperatures of the CPU(s) 1106, GPU(s) 1108, and / or accelerator 1114. If temperatures are determined to exceed a threshold, the boot and power management processor may enter a temperature fault routine and place the SoC(s) 1104 into a low-power state and / or place the vehicle 102 into a chauffeur-to-safe-stop mode (e.g., bring the vehicle 102 to a safe stop).

[0231] The processor(s) 110 may further include a set of embedded processors that can serve as an audio processing engine. The audio processing engine may be an audio subsystem that enables full hardware support for multi-channel audio across multiple interfaces and a wide and flexible range of audio I / O interfaces. In some examples, the audio processing engine is a dedicated processor core with a digital signal processor with dedicated RAM.

[0232] The processor(s) 1110 may further include an always-on processor engine that may provide necessary hardware features to support low-power sensor management and wake-up use cases. The always-on processor engine may include a processor core, tightly coupled RAM, peripheral support (e.g., timers and interrupt controllers), various I / O controller peripherals, and routing logic.

[0233] The processor(s) 1110 may further include a safety cluster engine, which includes a dedicated processor subsystem for handling safety management for automotive applications. The safety cluster engine may include two or more processor cores, tightly coupled RAM, peripheral support (e.g., timers and interrupt controllers), and / or routing logic. In a safety mode, the two or more cores may operate in a lockstep mode, acting as a single core with comparison logic to detect any differences between their operations.

[0234] The processor(s) 1110 may further include a real-time camera engine, which may include a dedicated processor subsystem for handling real-time camera management.

[0235] The processor(s) 1110 may further include a high dynamic range signal processor, which may include an image signal processor that is a hardware engine that is part of the camera processing pipeline.

[0236] The processor(s) 1110 may include a video image compositor, which may be a processing block (e.g., implemented on a microprocessor) that implements video post-processing functions required by a video playback application to generate the final image for the player window. The video image compositor may perform lens distortion correction on the wide-angle camera(s) 1170, the surround camera(s) 1174, and / or on camera sensors mounted in the cabin. An in-cabin surveillance camera sensor is preferably monitored by a neural network running on another instance of the Advanced SoC and configured to identify events in the cabin and respond accordingly.An in-cab system can perform lip reading to activate cellular service and make a call, dictate emails, change the vehicle's destination, activate or change the vehicle's infotainment system and settings, or provide voice-activated internet browsing. Certain functions are available to the driver only when the vehicle is operating in autonomous mode and are disabled otherwise.

[0237] The video image compositor may incorporate enhanced temporal noise reduction for both spatial and temporal noise reduction. For example, when motion occurs in a video, the noise reduction weights spatial information accordingly, reducing the weight of information provided by neighboring frames. When an image or part of an image contains no motion, the temporal noise reduction performed by the video image compositor may use information from the previous frame to reduce noise in the current frame.

[0238] The video image compositor may also be configured to perform stereo rectification on input stereo lens frames. The video image compositor may further be used for user interface composition when the operating system desktop is in use, so that the GPU(s) 1108 do not need to continuously render new surfaces. Even when the GPU(s) 1108 are powered on and active and actively performing 3D rendering, the video image compositor may be used to offload the GPU(s) 1108 to improve performance and responsiveness.

[0239] The SoC(s) 1104 may further include a serial MIPI (Mobile Industry Processor Interface) camera interface for receiving video and input from cameras, a high-speed interface, and / or a video input block that may be used for camera and related pixel input functions. The SoC(s) 1104 may further include one or more input / output controllers that may be controlled by software and used to receive I / O signals that are not dedicated to a specific role.

[0240] The SoC(s) 1104 may further include a wide range of peripheral interfaces to enable communication with peripherals, audio codecs, power management, and / or other devices. The SoC(s) 1104 may be used to process data from cameras (e.g., connected via Gigabit Multimedia Serial Link and Ethernet), sensors (e.g., LIDAR sensor(s) 1164, RADAR sensor(s) 1160, etc., which may be connected via Ethernet), data from the bus 1102 (e.g., the speed of the vehicle 102, steering wheel position, etc.), and data from GNSS sensor(s) 1158 (e.g., connected via Ethernet or CAN bus). The SoC(s) 1104 may further include dedicated high-performance mass storage controllers, which may include their own DMA engines and which may be used to free the CPU(s) 1106 from routine data management tasks.

[0241] The SoC(s) 1104 may be an end-to-end platform with a flexible architecture spanning automation levels 3-5, thereby providing a comprehensive functional safety architecture that leverages and efficiently utilizes computer vision and ADAS techniques for diversity and redundancy, and provides a platform for a flexible, reliable driver software stack, along with deep learning tools. The SoC(s) 1104 may be faster, more reliable, and even more power- and space-efficient than conventional systems. For example, the accelerator pedal(s) 1114, in combination with the CPU(s) 1106, GPU(s) 1108, and data storage(s) 1116, may provide a fast, efficient platform for Level 3-5 autonomous vehicles.

[0242] The technology thus provides capabilities and functionality that cannot be achieved with conventional systems. For example, computer vision algorithms can be executed on CPUs, which can be configured using a high-level programming language, such as the C programming language, to perform a variety of processing algorithms on a variety of visual data. However, CPUs are often unable to meet the performance requirements of many computer vision applications, such as those related to execution time and power consumption. In particular, many CPUs are unable to execute complex object detection algorithms in real time, which is a necessity for in-vehicle ADAS applications and a necessity for practical Level 3-5 autonomous vehicles.

[0243] In contrast to conventional systems, the technology described herein enables the simultaneous and / or sequential execution of multiple neural networks and the combination of the results to enable Level 3-5 autonomous driving functionality by providing a CPU complex, a GPU complex, and a hardware acceleration cluster. For example, a CNN running on the DLA or the dGPU (e.g., GPU(s) 1120) may include text and word recognition, which enables the supercomputer to read and understand traffic signs, including signs for which the neural network has not been specifically trained. The DLA may further include a neural network capable of identifying, interpreting, and semantically understanding a sign and passing this semantic understanding to the path planning modules running on the CPU complex.

[0244] As another example, multiple neural networks can operate simultaneously, as required for Level 3, 4, or 5 driving. For example, a warning sign consisting of "Caution: Flashing lights indicate icy conditions" along with an electric light can be interpreted independently or jointly by multiple neural networks. The sign itself can be identified as a traffic sign by a first deployed neural network (e.g., a trained neural network), and the text "Flashing lights indicate icy conditions" can be interpreted by a second deployed neural network, which informs the vehicle's path planning software (preferably running on the CPU complex) that icy conditions exist upon detection of flashing lights.The flashing light can be identified by running a third deployed neural network across multiple frames, informing the vehicle's path planning software of the presence (or absence) of flashing lights. All three neural networks can run concurrently, such as within the DLA and / or on the GPU(s) 1108.

[0245] In some examples, a CNN for facial recognition and vehicle owner identification may use data from camera sensors to identify the presence of an authorized driver and / or owner of vehicle 102. The always-on sensor processing engine may be used to unlock the vehicle when the owner approaches the driver's door and turn on the lights, and, in security mode, disarm the vehicle when the owner exits the vehicle. In this way, the SoC(s) 1104 provides protection against theft and / or car theft.

[0246] In another example, a CNN for emergency vehicle detection and identification may use data from microphones 1196 to detect and identify emergency vehicle sirens. Unlike conventional systems that use general classifiers to detect sirens and manually extract features, the SoC(s) 1104 uses the CNN to classify ambient and urban noise, as well as to classify visual data. In a preferred embodiment, the CNN running on the DLA is trained to identify the relative approach speed of the emergency vehicle (e.g., using the Doppler effect). The CNN may also be trained to identify emergency vehicles specific to the local area in which the vehicle is operating, as identified by the GNSS sensor(s) 1158.For example, if operating in Europe, the CNN will attempt to detect European sirens, and if operating in the United States, the CNN will attempt to identify only North American sirens. Once an emergency vehicle is detected, a control program can be used to execute an emergency vehicle safety routine using ultrasonic sensors 1162, slowing the vehicle, pulling to the side of the road, parking the vehicle, and / or idling the vehicle until the emergency vehicle(s) pass by.

[0247] The vehicle may include one or more CPU(s) 1118 (e.g., discrete CPU(s) or dCPU(s)) that may be coupled to the SoC(s) 1104 via a high-speed connection (e.g., PCIe). The CPU(s) 1118 may include, for example, an x86 processor. The CPU(s) 1118 may be used to perform a variety of functions, including arbitrating potentially inconsistent results between ADAS sensors and the SoC(s) 1104 and / or monitoring the state and health of the controller(s) 1136 and / or the infotainment SoC 1130, for example.

[0248] The vehicle 102 may include one or more GPU(s) 1120 (e.g., discrete GPU(s) or dGPU(s)) that may be coupled to the SoC(s) 1104 via a high-speed interconnect (e.g., NVIDIA's NVLINK). The GPU(s) 1120 may provide additional artificial intelligence functionality, such as by executing redundant and / or different neural networks, and may be used to train and / or update neural networks based at least in part on inputs (e.g., sensor data) from sensors of the vehicle 102.

[0249] The vehicle 102 may further include the network interface 1124, which may include one or more wireless antennas 1126 (e.g., one or more wireless antennas for various communication protocols, such as a cellular antenna, a Bluetooth antenna, etc.). The network interface 1124 may be used to enable wireless connectivity over the internet to the cloud (e.g., to the server(s) 104 and / or other network devices), to other vehicles, and / or to computing devices (e.g., passenger client devices). To communicate with other vehicles, a direct connection between the two vehicles and / or an indirect connection (e.g., via networks and over the internet) may be established. Direct connections may be provided via a vehicle-to-vehicle communication link.The vehicle-to-vehicle communication link may provide information to the vehicle 102 about vehicles in the vicinity of the vehicle 102 (e.g., vehicles in front of, to the side of, and / or behind the vehicle(s) 102). This functionality may be part of a cooperative adaptive cruise control functionality of the vehicle 102.

[0250] The network interface 1124 may include a SoC that provides modulation and demodulation functionality and enables the controller(s) to communicate over wireless networks. The network interface 1124 may include a radio frequency front-end for upconversion from baseband to radio frequency and downconversion from radio frequency to baseband. The frequency conversions may be performed using well-known methods and / or may be performed using superheterodyne techniques. In some examples, the radio frequency front-end functionality may be provided by a separate chip. The network interface may include wireless functionality for communicating over LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth, LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN, and / or other wireless protocols.

[0251] The vehicle 102 may further include one or more data storage devices 1128, which may also include off-chip memory (e.g., outside of the SoC(s) 1104). The data storage devices 1128 may include one or more memory elements, including RAM, SRAM, DRAM, VRAM, flash, hard drives, and / or other components and / or devices capable of storing at least one bit of data.

[0252] The vehicle 102 may further include one or more GNSS sensors 1158 (e.g., GPS and / or assisted GPS sensors) to support mapping, sensing, occupancy network generation, and / or path planning functions. Any number of GNSS sensors 1158 may be used, including, for example, and without limitation, a GPS using a USB port with an Ethernet-to-serial (RS-232) bridge.

[0253] The vehicle 102 may further include one or more RADAR sensors 1160. The RADAR sensor(s) 1160 may be used by the vehicle 102 for wide-area vehicle detection, even in darkness and / or extreme weather conditions. RADAR functional safety levels may be ASIL B. The RADAR sensor(s) 1160 may use CAN and / or bus 1102 for control (e.g., to transmit data generated by the RADAR sensor(s) 1160) and to access object tracking data, with, in some examples, access to Ethernet for accessing raw data. A variety of RADAR sensor types may be used. For example, and without limitation, the RADAR sensor(s) 1160 may be suitable for front-facing, rear-facing, and side-facing RADAR deployment. In some examples, pulse Doppler radar sensors are used.

[0254] The RADAR sensor(s) 1160 may include various configurations, such as long-range and narrow field of view, short-range with wide field of view, short-range with side coverage, etc. In some examples, the long-range RADAR may be used for adaptive cruise control functionality. The long-range RADAR systems may provide a wide field of view realized by two or more independent scans, for example, within a 250 m radius. The RADAR sensor(s) 1160 may assist in distinguishing between static and moving objects and may be used by ADAS systems for emergency braking assistance and forward collision warning. Long-range RADAR sensors may include monostatic multimodal RADAR with multiple (e.g., six or more) fixed RADAR antennas and a fast CAN and FlexRay interface.In a six-antenna example, the central four antennas can create a focused beam pattern designed to capture the surroundings of vehicle 102 at higher speeds with minimal interference from traffic in adjacent lanes. The other two antennas can expand the field of view so that vehicles entering or exiting the lane of vehicle 102 can be quickly detected.

[0255] Medium-range radar systems, for example, can have a range of up to 1,460 m (front) or 80 m (rear) and a field of view of up to 42 degrees (front) or 1,450 degrees (rear). Short-range radar systems can include, but are not limited to, radar sensors designed for installation at either end of the rear bumper. When installed at either end of the rear bumper, such a radar sensor system can create two beams that continuously monitor the blind spot area at the rear and to the side of the vehicle.

[0256] Short-range radar systems can be used in an ADAS system to detect blind spots and / or assist with lane changes.

[0257] The vehicle 102 may further include one or more ultrasonic sensors 1162. The ultrasonic sensor(s) 1162, which may be positioned at the front, rear, and / or sides of the vehicle 102, may be used for parking assistance and / or for creating and updating an occupancy grid. A wide range of ultrasonic sensors 1162 may be used, and different ultrasonic sensors 1162 may be used for different detection ranges (e.g., 2.5 m, 4 m). The ultrasonic sensor(s) 1162 may operate at functional safety levels of ASIL B.

[0258] The vehicle 102 may include LIDAR sensor(s) 1164. The LIDAR sensor(s) 1164 may be used for object and pedestrian detection, emergency braking, collision avoidance, and / or other functions. The LIDAR sensor(s) 1164 may be functionally safe to ASIL B. In some examples, the vehicle 102 may include multiple LIDAR sensors 1164 (e.g., two, four, six, etc.) that may use Ethernet (e.g., to deliver data to a Gigabit Ethernet switch).

[0259] In some examples, the LIDAR sensor(s) 1164 may be capable of providing a list of objects and their distances for a 360-degree field of view. For example, commercially available LIDAR sensor(s) 1164 may have an advertised range of approximately 1400 m, with an accuracy of 2 cm-3 cm, and supporting a 1400 Mbps Ethernet connection. In some examples, one or more non-prominent LIDAR sensors 1164 may be used. In such examples, the LIDAR sensor(s) 1164 may be implemented as a small device that may be embedded in the front, rear, sides, and / or corners of the vehicle 102. In such examples, the LIDAR sensor(s) 1164 may provide up to 1420 degrees of horizontal field of view and 35 degrees of vertical field of view, with a range of 200 meters even for objects with low reflectivity.Front-mounted LIDAR sensor(s) 1164 can be configured for a horizontal field of view between 45 degrees and 135 degrees.

[0260] In some examples, LIDAR technologies such as 3D flash LIDAR may also be used. 3D flash LIDAR uses a laser flash as a transmission source to illuminate the vehicle's surroundings out to approximately 200 m. A flash LIDAR unit includes a receptor that records the laser pulse travel time and the reflected light on each pixel, which in turn corresponds to the range from the vehicle to the objects. Flash LIDAR can enable highly accurate and distortion-free images of the surroundings to be generated with each laser flash. In some examples, four flash LIDAR sensors may be deployed, one on each side of the vehicle 102. Available 3D flash LIDAR systems include a solid-state 3D star-field LIDAR camera with no moving parts other than a fan (e.g., a non-scanning LIDAR device).The flash lidar device can use a 5-nanosecond Class I (eye-safe) laser pulse per frame and can capture the reflected laser light as 3D area point clouds and co-registered intensity data. By using flash lidar, and because flash lidar is a solid-state device with no moving parts, the lidar sensor(s) 1164 can be less susceptible to motion blur, vibration, and / or shock.

[0261] The vehicle may further include one or more IMU sensors 1166. The IMU sensor(s) 1166 may, in some examples, be located at a center of the rear axle of the vehicle 102. The IMU sensor(s) 1166 may, for example, include one or more accelerometers, magnetometers, gyroscopes, magnetic compasses, and / or other sensor types. In some examples, such as in six-axis applications, the IMU sensor(s) 1166 may include accelerometers and gyroscopes, while in nine-axis applications, the IMU sensor(s) 1166 may include accelerometers, gyroscopes, and magnetometers.

[0262] In some embodiments, the IMU sensor(s) 1166 may be implemented as a miniaturized, high-performance GPS-based inertial navigation system (GPS / INS) that combines micro-electromechanical system (MEMS) inertial sensors, a high-sensitivity GPS receiver, and advanced Kalman filter algorithms to provide estimates of position, velocity, and attitude. As such, in some examples, the IMU sensor(s) 1166 may enable the vehicle 102 to estimate heading without requiring input from a magnetic sensor by directly observing and correlating velocity changes from the GPS to the IMU sensor(s) 1166. In some examples, the IMU sensor(s) 1166 and the GNSS sensor(s) 1158 may be combined into a single integrated unit.

[0263] The vehicle may include one or more microphones 1196 placed in and / or around the vehicle 102. The microphone(s) 1196 may be used, among other things, to detect and identify emergency vehicles.

[0264] The vehicle may further include any number of camera types, including stereo camera(s) 1168, wide-view camera(s) 1170, infrared camera(s) 1172, surround camera(s) 1174, long-range and / or mid-range camera(s) 1198, and / or other camera types. The cameras may be used to capture image data across an entire periphery of the vehicle 102. The camera types used depend on the embodiments and requirements for the vehicle 102, and any combination of camera types may be used to provide the required coverage around the vehicle 102. Furthermore, the number of cameras may vary depending on the embodiment. For example, the vehicle may include six cameras, seven cameras, ten cameras, twelve cameras, and / or another number of cameras.For example, and without limitation, the cameras may support Gigabit Multimedia Serial Link (GMSL) and / or Gigabit Ethernet. Each of the camera(s) is referred to herein with reference to . Fig. 11A and Fig. 11B is described in more detail.

[0265] The vehicle 102 may further include one or more vibration sensors 1142. The vibration sensor(s) 1142 may measure oscillations or vibrations of components of the vehicle, such as the axle(s). For example, changes in the vibrations may indicate a change in the road surface. In another example, when two or more vibration sensors 1142 are used, the differences between the vibrations may be used to determine the friction or slippage of the road surface (e.g., when the vibration change occurs between a driven axle and a freely rotating axle).

[0266] The vehicle 102 may include an ADAS system 1138. The ADAS system 1138 may include an SoC in some examples. The ADAS system 1138 may include autonomous / adaptive / automatic cruise control (ACC), cooperative adaptive cruise control (CACC), forward collision warning (FCW), automatic emergency braking (AEB), lane departure warning (LDW), lane keep assist (LKA), blind spot warning (BSW), rear cross traffic alert (RCTW), collision warning (CWS), lane centering (LC), and / or other features and functionality.

[0267] The ACC systems may use one or more RADAR sensors 1160, one or more LIDAR sensors 1164, and / or one or more cameras. The ACC systems may include longitudinal ACC and / or lateral ACC. Longitudinal ACC monitors and controls the distance to the vehicle immediately ahead of vehicle 102 and automatically adjusts the vehicle speed to maintain a safe distance from preceding vehicles. Lateral ACC performs follow-through and instructs vehicle 102 to change lanes if necessary. Lateral ACC is related to other ADAS applications such as LCA and CWS.

[0268] CACC utilizes information from other vehicles, which may be received via the network interface 1124 and / or the wireless antenna(s) 1126 from other vehicles over a wireless connection or indirectly via a network connection (e.g., over the Internet). Direct connections may be provided via a vehicle-to-vehicle (V2V) communication link, while indirect connections may be infrastructure-to-vehicle (I2V) communication links. In general, the V2V communication concept provides information about the immediately preceding vehicles (e.g., vehicles immediately in front of and in the same lane as vehicle 102), while the I2V communication concept provides information about traffic further ahead. CACC systems may incorporate either or both of the I2V and V2V information sources.Given the information from the vehicles ahead of vehicle 102, CACC can be more reliable and has the potential to improve traffic flow smoothness and reduce congestion on the road.

[0269] FCW systems are designed to warn the driver of a hazard so the driver can take corrective action. FCW systems utilize a forward-facing camera and / or one or more radar sensors 1160 coupled to a dedicated processor, DSP, FPGA, and / or ASIC, which is electrically coupled to driver feedback, such as a display, speaker, and / or vibration component. FCW systems can trigger a warning, e.g., in the form of a sound, a visual warning, a vibration, and / or a rapid braking pulse.

[0270] AEB systems detect an impending forward collision with another vehicle or object and can automatically apply the brakes if the driver does not take corrective action within a specified time or distance parameter. AEB systems can utilize forward-facing camera(s) and / or radar sensor(s) 1160 coupled with a dedicated processor, DSP, FPGA, and / or ASIC. When the AEB system detects a hazard, it typically first alerts the driver to take corrective action to avoid the collision. If the driver does not take corrective action, the AEB system can then automatically apply the brakes to prevent or at least mitigate the effects of the predicted collision. AEB systems can incorporate techniques such as dynamic brake support and / or crash-inducing braking.

[0271] LDW systems provide visual, audible, and / or tactile warnings, such as steering wheel or seat vibrations, to alert the driver when the vehicle 102 crosses lane markings. An LDW system will not activate if the driver indicates an intentional lane departure by activating a turn signal. LDW systems may utilize forward-facing cameras coupled with a dedicated processor, DSP, FPGA, and / or ASIC that is electrically coupled to driver feedback, such as a display, speaker, and / or vibration component.

[0272] LKA systems are a variant of LDW systems. LKA systems provide steering inputs or braking to correct the vehicle 102 if the vehicle 102 begins to depart from the lane.

[0273] BSW systems detect and warn the driver of vehicles in a vehicle's blind spot. BSW systems can trigger a visual, audible, and / or tactile alert to indicate that entering or changing lanes is unsafe. The system can provide an additional warning if the driver uses a turn signal. BSW systems can utilize rear-facing camera(s) and / or radar sensor(s) 1160 coupled to a dedicated processor, DSP, FPGA, and / or ASIC that is electrically coupled to driver feedback, such as a display, speaker, and / or vibration component.

[0274] RCTW systems may provide visual, audible, and / or tactile notification when an object outside the rearview camera range is detected when the vehicle 102 is reversing. Some RCTW systems include AEB to ensure the vehicle brakes are applied to avoid a crash. RCTW systems may utilize one or more rear-facing RADAR sensors 1160 coupled to a dedicated processor, DSP, FPGA, and / or ASIC that is electrically coupled to driver feedback, such as a display, speaker, and / or vibration component.

[0275] Conventional ADAS systems can be prone to false positives, which can be annoying and disruptive for a driver, but are typically not catastrophic because the ADAS systems warn the driver and allow the driver to decide whether a safety condition actually exists and act accordingly. However, in an autonomous vehicle 102, when conflicting results occur, the vehicle 102 must decide whether to consider the result from a primary computer or a secondary computer (e.g., a first controller 1136 or a second controller 1136). For example, in some embodiments, the ADAS system 1138 may be a backup and / or secondary computer for providing perception information to a rationality module of the backup computer.The backup computer's rationality monitor can run redundant, diverse software on hardware components to detect perceptual errors and dynamic driving tasks. Outputs from the 1138 ADAS system can be delivered to a higher-level MCU. If outputs from the primary computer and the secondary computer conflict, the higher-level MCU must determine how to resolve the conflict to ensure safe operation.

[0276] In some examples, the primary computer may be configured to provide the parent MCU with a confidence score indicating the primary computer's confidence in the chosen outcome. If the confidence score exceeds a threshold, the parent MCU may follow the primary computer's direction regardless of whether the secondary computer provides a conflicting or inconsistent result. If the confidence score does not meet the threshold and if the primary and secondary computers indicate different results (e.g., a conflict), the parent MCU may mediate between the computers to determine the appropriate outcome.

[0277] The master MCU may be configured to operate one or more neural networks trained and configured to determine, based at least in part on outputs from the primary computer and the secondary computer, conditions under which the secondary computer will deliver false alarms. Consequently, the neural network(s) in the master MCU may learn when the output of the secondary computer is trustworthy and when it is not. For example, if the secondary computer is a radar-based FCW system, a neural network in the master MCU may learn when the FCW system identifies metallic objects that are not actually hazards, such as a drainage grate or manhole cover, which triggers an alarm.Similarly, if the secondary computer is a camera-based LDW system, a neural network in the parent MCU can learn to override the LDW when cyclists or pedestrians are present and leaving a lane is actually the safest maneuver. In embodiments that include one or more neural networks executing on the parent MCU, the parent MCU can include at least one of a DLA or GPU suitable for operating the neural network(s) with associated memory. In preferred embodiments, the parent MCU can comprise the SoC(s) and / or be included as a component of the SoC(s) 1104.

[0278] In other examples, the ADAS system 1138 may include a secondary computer that performs the ADAS functionality using traditional computer vision rules. As such, the secondary computer may use classic computer vision rules (if-then), and the presence of one or more neural networks in the parent MCU may improve reliability, safety, and performance. For example, the diverse implementation and intentional non-identity make the overall system more fault-tolerant, particularly against errors caused by software functionality (or the software-hardware interface).For example, if there is a software bug or a defect in the software running on the primary computer and the non-identical software code running on the secondary computer produces the same overall result, the parent MCU can have greater confidence that the overall result is correct and the software or hardware defect on the primary computer does not cause a significant failure.

[0279] In some examples, the output of the ADAS system 1138 may be fed into the perception block of the primary computer and / or the dynamic driving task block of the primary computer. For example, if the ADAS system 1138 displays a forward crash warning due to an object immediately ahead, the perception block may use this information when identifying objects. In other examples, the secondary computer may have its own neural network trained to reduce the risk of false alarms, as described herein.

[0280] The vehicle 102 may further include the infotainment SoC 1130 (e.g., an in-vehicle infotainment (IVI) system). Although illustrated and described as an SoC, the infotainment system may not be an SoC and may include two or more discrete components. The infotainment SoC 1130 may include a combination of hardware and software that can be used to provide audio (e.g., music, a personal digital assistant, navigation instructions, news, radio, etc.), video (e.g., TV, movies, streaming, etc.), phone (e.g., hands-free calling), network connectivity (e.g., LTE, Wi-Fi, etc.), and / or information services (e.g., navigation systems, backup assist, a radio data system, vehicle-related information such as fuel level, total distance traveled, brake fluid level, oil level, door open / closed, air filter information, etc.) to the vehicle 102.For example, the infotainment SoC 1130 may include radios, a disk player, navigation systems, a video player, USB and Bluetooth connectivity, a car computer, in-car entertainment, Wi-Fi, steering wheel audio controls, a hands-free function, a heads-up display (HUD), an HMI display 1134, a telematics device, a control panel (e.g., for controlling and / or interacting with various components, functions, and / or systems), and / or other components. The infotainment SoC 1130 may further be used to provide information (e.g., visual and / or audible) to one or more users of the vehicle, such as information from the ADAS system 1138, autonomous driving information such as planned vehicle maneuvers, trajectories, environmental information (e.g., intersection information, vehicle information, road information, etc.), and / or other information.

[0281] The infotainment SoC 1130 may include GPU functionality. The infotainment SoC 1130 may communicate with other devices, systems, and / or components of the vehicle 102 via the bus 1102 (e.g., CAN bus, Ethernet, etc.). In some examples, the infotainment SoC 1130 may be coupled to a higher-level MCU such that the infotainment system's GPU may perform some self-driving functions if the primary controller(s) 1136 (e.g., the primary and / or backup computer of the vehicle 102) fail. In such an example, the infotainment SoC 1130 may place the vehicle 102 into a chauffeur-in-safe-stop mode, as described herein.

[0282] The vehicle 102 may further include an instrument cluster 1132 (e.g., a digital instrument panel, an electronic instrument cluster, a digital instrument panel, etc.). The instrument cluster 1132 may include a controller and / or a supercomputer (e.g., a discrete controller or a supercomputer). The instrument cluster 1132 may include a number of instruments, such as a speedometer, fuel level, oil pressure, a tachometer, an odometer, turn signals, a shift position indicator, one or more seat belt warning lights, one or more parking brake warning lights, one or more engine malfunction lights, airbag (SRS) system information, lighting controls, safety system controls, navigation information, etc. In some examples, information may be displayed and / or shared between the infotainment SoC 1130 and the instrument cluster 1132.In other words, the instrument cluster 1132 may be included as part of the infotainment SoC 1130, or vice versa.

[0283] Fig. 11D is a system diagram for communication between one or more cloud-based servers and the example autonomous vehicle 102 of Fig. 11A, according to some embodiments of the invention. The autonomous vehicle system 100 may include one or more servers 104, one or more networks 1190, and vehicles, including the vehicle 102. The server(s) 104 may include a plurality of GPUs 1184(A)-1184(H) (collectively referred to herein as GPUs 1184), PCIe switches 1182(A)-1182(H) (collectively referred to herein as PCIe switches 1182), and / or CPUs 1180(A)-1180(B) (collectively referred to herein as CPUs 1180). The GPUs 1184, the CPUs 1180, and the PCIe switches may be connected via high-speed interconnects such as, but not limited to, the NVIDIA-developed NVLink interfaces 1188 and / or PCIe interconnects 1186. In some examples, the GPUs 1184 are connected via NVLink and / or NVSwitch SoC, and the GPUs 1184 and the PCIe switches 1182 are connected via PCIe interconnects.Although eight GPUs 1184, two CPUs 1180, and two PCIe switches are illustrated, this is not intended to be limiting. Depending on the embodiment, each of the servers 104 may include any number of GPUs 1184, CPUs 1180, and / or PCIe switches. For example, the server(s) 104 may each include eight, sixteen, thirty-two, and / or more GPUs 1184.

[0284] The server(s) 104 may receive, via the network(s) 1190 and from the vehicles, image data representative of images depicting unexpected or changed road conditions, such as recently commenced roadwork. The server(s) 104 may transmit, via the network(s) 1190 and to the vehicles, neural networks 1192, updated neural networks 1192, and / or map information 1194, including information about traffic and road conditions. The updates to the map information 1194 may include updates to the HD map 1122, such as information about construction, potholes, detours, flooding, and / or other obstacles.In some examples, the neural networks 1192, the updated neural networks 1192, and / or the map information 1194 may be derived from new training and / or experience represented in data received from any number of vehicles in the environment, and / or may be based at least in part on training performed in a data center (e.g., using the server(s) 104 and / or other servers).

[0285] The server(s) 104 may be used to train machine learning models (e.g., neural networks) based on training data. The training data may be generated by the vehicles and / or may be created in a simulation (e.g., using a game engine). In some examples, the training data is tagged (e.g., if the neural network benefits from supervised learning) and / or subjected to other preprocessing, while in other examples, the training data is not tagged and / or preprocessed (e.g., if the neural network does not require supervised learning). Once the machine learning models are trained, the machine learning models may be used by the vehicles (e.g.,transmitted to the vehicles via the network(s) 1190), and / or the machine learning models may be used by the server(s) 104 to remotely monitor the vehicles.

[0286] In some examples, the server(s) 104 may receive data from the vehicles and apply the data to real-time neural networks for intelligent real-time inference. The server(s) 104 may include deep learning supercomputers and / or dedicated AI computers powered by GPU(s) 1184, such as DGX and DGX Station machines developed by NVIDIA. However, in some examples, the server(s) 104 may include a deep learning infrastructure using only CPU-powered data centers.

[0287] The deep learning infrastructure of server(s) 104 may be capable of fast, real-time inference and may utilize this capability to evaluate and verify the state of the processors, software, and / or associated hardware in vehicle 102. For example, the deep learning infrastructure may receive regular updates from vehicle 102, such as a sequence of images and / or objects that vehicle 102 has located within that sequence of images (e.g., through computer vision and / or other learning object classification techniques).The deep learning infrastructure can run its own neural network to identify the objects and compare them with the objects identified by the vehicle 102, and then, if the results do not match and the infrastructure concludes that the AI ​​in the vehicle 102 is malfunctioning, the server(s) 104 can send a signal to the vehicle 102 instructing a fail-safe computer of the vehicle 102 to take over control, notify the passengers, and complete a safe parking maneuver.

[0288] For inferencing, the server(s) 104 may include the GPU(s) 1184 and one or more programmable inference accelerators (e.g., NVIDIA's TensorRT 3). The combination of GPU-powered servers and inference acceleration may enable real-time responsiveness. In other examples, such as when performance is less critical, servers powered by CPUs, FPGAs, and other processors may be used for inferencing. Example computing device

[0289] Fig. 12 is a block diagram of an exemplary computing device 1200 suitable for use in implementing some embodiments of the invention. Computing device 1200 may include a bus 1202 that directly or indirectly couples the following devices: memory 1204, one or more central processing units (CPUs) 1206, one or more graphics processing units (GPUs) 1208, a communications interface 1210, input / output (I / O) ports 1212, input / output components 1214, a power supply 1216, and one or more presentation components 1218 (e.g., display(s)).

[0290] Although the different blocks of Fig. 12 are shown as being connected to lines via bus 1202, this is not limiting and is for clarity only. For example, in some embodiments, a presentation component 1218, such as a display device, may be considered an I / O component 1214 (e.g., if the display is a touchscreen). As another example, the CPUs 1206 and / or the GPUs 1208 may include memory (e.g., memory 1204 may be representative of a memory device in addition to the memory of the GPUs 1208, the CPUs 1206, and / or other components). In other words, the computing device of Fig. 12 is merely illustrative. It does not distinguish between categories such as "workstation", "server", "laptop", "desktop", "tablet", "client device", "mobile device", "handheld device", "game console", "electronic control unit (ECU)", "virtual reality system" and / or other types of devices or systems, all of which are within the scope of the computing device of Fig. 12 are conceivable.

[0291] Bus 1202 may represent one or more buses, such as an address bus, a data bus, a control bus, or a combination thereof. Bus 1202 may include one or more bus types, such as an Industry Standard Architecture (ISA) bus, an Extended Industry Standard Architecture (EISA) bus, a Video Electronics Standards Association (VESA) bus, a Peripheral Component Interconnect (PCI) bus, a Peripheral Component Interconnect Express (PCIe) bus, and / or another type of bus.

[0292] Memory 1204 may include any of a variety of computer-readable media. The computer-readable media may be any available media accessible by computing device 1200. The computer-readable media may include both volatile and non-volatile media, as well as removable and non-removable media. By way of example and not limitation, the computer-readable media may include computer storage media and communication media.

[0293] The computer storage media may include both volatile and non-volatile media and / or removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, and / or other data types. For example, memory 1204 may store computer-readable instructions (e.g., those representing one or more programs and / or one or more program elements, such as an operating system).Computer storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, Digital Versatile Disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing device 1200. As used herein, computer storage media does not include signals per se.

[0294] The communication media may embody computer-readable instructions, data structures, program modules, and / or other data types in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information-delivering media. The term "modulated data signal" may refer to a signal having one or more of its properties fixed or altered such that information is encoded in the signal. By way of example and not limitation, the communication media may include wired media, such as a wired network or a direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of any of the foregoing should also be considered within the scope of computer-readable media.

[0295] The CPU(s) 1206 may be configured to execute the computer-readable instructions to control one or more components of the computing device 1200 to perform one or more of the methods and / or processes described herein. The CPU(s) 1206 may each include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of concurrently processing a plurality of software threads. The CPU(s) 1206 may include any type of processor and may include different types of processors depending on the type of computing device 1200 implemented (e.g., processors with fewer cores for mobile devices and processors with more cores for servers).Depending on the type of computing device 1200, the processor may be, for example, an ARM processor implemented using Reduced Instruction Set Computing (RISC) or an x86 processor implemented using Complex Instruction Set Computing (CISC).

[0296] The computing device 1200 may include one or more CPUs 1206 in addition to one or more microprocessors or additional co-processors, such as math co-processors.

[0297] The GPU(s) 1208 may be used by the computing device 1200 to render graphics (e.g., 3D graphics). The GPU(s) 1208 may include hundreds or thousands of cores capable of processing hundreds or thousands of software threads simultaneously. The GPU(s) 1208 may generate pixel data for output images in response to rendering commands (e.g., rendering commands from the CPU(s) 1206 received via a host interface). The GPU(s) 1208 may include graphics memory, such as display memory, for storing pixel data. The display memory may be included as part of the memory 1204. The GPU(s) 1208 may include two or more GPU(s) operating in parallel (e.g., via an interconnect). In combination, each GPU can generate 1208 pixel data for different sections of an output image or for different output images (e.g., a first GPU for a first image and a second GPU for a second image).Each GPU can contain its own memory, or can share memory with other GPUs.

[0298] In examples where the computing device 1200 does not include the GPU(s) 1208, the CPU(s) 1206 may be used to render graphics.

[0299] The communication interface 1210 may include one or more receivers, transmitters, and / or transceivers that enable the computing device 1200 to communicate with other computing devices over an electronic communication network, including wired and / or wireless communication. The communication interface 1210 may include components and functions to enable communication over any of a number of different networks, such as wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g., communication over Ethernet), low-power wide-area networks (e.g., LoRaWAN, SigFox, etc.), and / or the Internet.

[0300] The I / O ports 1212 may enable the computing device 1200 to be logically coupled to other devices, including the I / O components 1214, the presentation component(s) 1218, and / or other components, some of which may be built into (e.g., integrated) the computing device 1200. Illustrative I / O components 1214 include a microphone, a mouse, a keyboard, a joystick, a gamepad, a game controller, a satellite dish, a scanner, a printer, a wireless device, etc. The I / O components 1214 may provide a natural user interface (NUI) that processes air gestures, speech, or other physiological inputs generated by a user. In some cases, inputs may be transmitted to a suitable network element for further processing.A NUI may implement any combination of speech recognition, stylus recognition, facial recognition, biometric recognition, both on-screen and off-screen gesture recognition, air gestures, head and eye tracking, and touch sensing (as described in more detail below) in conjunction with a display of computing device 1200. Computing device 1200 may include depth cameras, such as stereoscopic camera systems, infrared camera systems, RGB camera systems, touchscreen technology, and combinations thereof, for gesture sensing and recognition. In addition, computing device 1200 may include accelerometers or gyroscopes (e.g., as part of an inertial measurement unit (IMU)) that enable motion sensing. In some examples, the output of the accelerometers or gyroscopes from computing device 1200 may be used to render immersive augmented reality or virtual reality.

[0301] Power supply 1216 may include a hardwired power supply, a battery power supply, or a combination thereof. Power supply 1216 may supply power to computing device 1200 to enable operation of the components of computing device 1200.

[0302] The presentation component(s) 1218 may include a display (e.g., a monitor, a touchscreen, a television monitor, a heads-up display (HUD), other display types, or a combination thereof), speakers, and / or other presentation components. The presentation component(s) 1218 may receive data from other components (e.g., the GPU(s) 1208, the CPU(s) 1206, etc.) and output the data (e.g., as an image, video, audio, etc.).

[0303] The invention may be described in the general context of computer code or machine-readable instructions, including computer-executable instructions, such as program modules, executed by a computer or other machine, such as a personal information assistant or other portable device. Generally, program modules, including routines, programs, objects, components, data structures, etc., refer to code that performs specific tasks or implements specific abstract data types. The invention may be practiced in a variety of system configurations, including portable devices, consumer electronics, general-purpose computers, more specialized computing devices, etc.The invention may also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communications network.

[0304] As used herein, a reference to "and / or" with respect to two or more elements should be interpreted to mean only one element or a combination of elements. For example, "element A, element B, and / or element C" can include only element A, only element B, only element C, element A and element B, element A and element C, element B and element C, or elements A, B, and C. Furthermore, "at least one of element A or element B" can include at least one of element A, at least one of element B, or at least one of element A and at least one of element B. Furthermore, "at least one of element A and element B" can include at least one of element A, at least one of element B, or at least one of element A and at least one of element B.

[0305] The subject matter of the invention is specifically described herein to comply with legal requirements. However, the description itself is not intended to limit the scope of this invention. Rather, the inventors contemplated that the claimed subject matter could be embodied in other ways to include different steps or combinations of steps similar to those described herein in conjunction with other present or future technologies. Although the terms "step" and / or "block" may be used herein to connote various elements of employed methods, the terms are not to be interpreted as implying any particular order between or among steps disclosed herein, unless, and exceptionally, the order of individual steps is expressly described.

Claims

[1] Method comprising: Determining a currently claimed set of points representative of a volume in an environment occupied by a vehicle at a time based at least in part on a size, position, and orientation of the vehicle; Generating one or more vehicle-occupied trajectories representative of first future claimed sets of points of the vehicle in the environment if the vehicle were to implement a first safety procedure at that time, based at least in part on one or more speeds of the vehicle at that time and the first safety procedure for the vehicle; Detecting an intersection point between the one or more vehicle-occupied trajectories and one or more object-occupied trajectories based at least in part on comparing the one or more vehicle-occupied trajectories with the one or more object-occupied trajectories, wherein the one or more object-occupied trajectories are representative of second future claimed sets of an object in the environment if the object were to implement a second security procedure associated with the object at that time; Calculating a first safety potential associated with the vehicle implementing the first safety procedure and the object implementing the second safety procedure, wherein the first safety potential is representative of the intersection point; and Executing, based at least in part on the intersection point, one of the first safety procedure or an alternative procedure that, when implemented by the vehicle when the object implements the second safety procedure, is determined to have a second safety potential calculated as having a lower probability of collision between the vehicle and the object than the first safety potential. [2] The method of claim 1, further comprising determining the speed, orientation, and position of the vehicle based at least in part on sensor data received from one or more sensors of the vehicle, wherein the one or more sensors include one or more of: a Global Navigation Satellite System (GNSS) sensor; a camera; an accelerometer; an inertial sensor; a gyro sensor; a compass; a tire vibration sensor; a microphone; a steering sensor; or a speed sensor. [3] The method of claim 1, further comprising determining a set of functions corresponding to a control policy representative of the first safety procedure for the vehicle by: determining control parameters for steering, braking, and acceleration for the vehicle; identifying a vehicle state target of the first safety procedure; analyzing sensor data received from one or more sensors of the vehicle to determine positions, orientations, and velocities of objects in the environment; and based at least in part on the control parameters and the positions, orientations, and velocities of the objects, determining the set of functions to guide the vehicle to the vehicle state target. [4] The method of claim 1, further comprising determining the size of the vehicle by: identifying a vehicle size of the vehicle; and adjusting a predefined shape around the vehicle based at least in part on at least one of the vehicle size and the vehicle type, wherein the size is of the predefined shape. [5] The method of claim 4, wherein determining the size of the vehicle further comprises identifying a safety margin, and wherein the predefined shape includes the safety margin. [6] The method of claim 1, further comprising determining the object-occupied trajectory for the object by determining at least one of an object speed, an object orientation, and at least one of an object position, an object size, or an object shape of the object in the environment based at least in part on sensor data received from one or more sensors of the vehicle, wherein the one or more sensors include one or more of: a GNSS (Global Navigation Satellite System) sensor; a long-range camera; a stereo camera; an infrared camera; a surround camera; a wide-angle camera; a mid-range camera; a LIDAR sensor; an ultrasonic sensor; an infrared sensor; a radar sensor; or a radio antenna. [7] The method of claim 1, wherein each first future claimed set of the first future claimed sets is representative of a respective volume in the environment that would be occupied by the vehicle at a respective future time. [8] Method comprising: Determining a currently claimed set of points representative of an area in the environment occupied by a vehicle at a time based at least in part on a state of the vehicle, the state including a position and a speed of the vehicle and at least one of a size, a shape, or a type of the vehicle; Generating a vehicle-occupied trajectory representative of first future occupied sets of the vehicle in the environment if the vehicle were to implement a safety procedure at that time, based at least in part on the state and the safety procedure for the vehicle; Comparing the vehicle-occupied trajectory with object-occupied trajectories associated with objects in the environment to detect whether any virtual intersection points occur between the vehicle-occupied trajectory and one or more of the object-occupied trajectories; and upon detection of a virtual intersection point, implementing a first set of controls defined by the safety procedure or a second set of controls defined by an alternative procedure determined to have a lower probability of occurrence of a real intersection point between the vehicle and an object of the objects associated with the virtual intersection point compared to the safety procedure. [9] The method of claim 8, wherein implementing the first set of controls or the second set of controls comprises: Calculating a first safety potential representative of a first probability of the real crossing point based at least in part on the first set of controls representative of the safety procedure; Calculating a second safety potential representative of a second probability of the real crossing point based at least in part on the second set of controls representative of the alternative procedure; Comparing the first safety potential with the second safety potential; and based at least in part on comparing: upon determining that the second probability is greater than the first probability, implementing the first set of controls; or upon determining that the second probability is equal to or less than the first probability, implementing the first set of controls or the second set of controls. [10] The method of claim 8, wherein the time is a current time plus an estimated latency, wherein the estimated latency is predefined or determined based at least in part on historical data associated with the vehicle. [11] The method of claim 8, further comprising generating the object-occupied trajectories by: Determining object states for each of the objects in the environment at the time based at least in part on sensor data received from one or more sensors of the vehicle, wherein each object state is representative of a respective position, orientation, and velocity of a respective object; Identifying object security procedures for each of the objects; and Generating the object-occupied trajectories based at least in part on the object states and the object security procedures. [12] The method of claim 8, further comprising determining the objects in the environment by: Analyzing the sensor data to identify perceived objects based at least in part on sensor data generated by one or more sensors of the vehicle; Analyzing at least one of the sensor data and map data to determine variables in the environment, wherein the variables include at least one of intersections, occluded objects, or traffic lights; and Identifying unperceived objects based at least in part on the variables, where the perceived objects and the unperceived objects are the objects. [13] The method of claim 8, further comprising: Determining, during implementation of the first set of controls or the second set of controls, that an updated vehicle-occupied trajectory no longer intersects an updated object-occupied trajectory; and Finish implementing the first set of controls or the second set of controls. [14] The method of claim 8, wherein the vehicle occupied trajectory is representative of the future occupied sets of the vehicle in the environment if the vehicle were to implement the safety procedure at that time over a range of braking profiles of the safety procedure, the range of braking profiles including a first braking profile and a second braking profile different from the first braking profile. [15] The method of claim 8, wherein comparing the vehicle-occupied trajectory with the object-occupied trajectories associated with the objects in the environment includes determining whether any first edges corresponding to the vehicle-occupied trajectory intersect any second edges corresponding to the object-occupied trajectories. [16] The method of claim 8, wherein comparing the vehicle-occupied trajectory with the object-occupied trajectories associated with the objects in the environment includes determining whether a vertex of the vehicle-occupied trajectory intersects an edge of any of the object-occupied trajectories. [17] The method of claim 8, wherein comparing the vehicle-occupied trajectory with the object-occupied trajectories associated with the objects in the environment includes determining whether a vertex of any of the object-occupied trajectories intersects an edge of the vehicle-occupied trajectory. [18] Method comprising: based at least in part on a vehicle state of a vehicle at a time and a first safety procedure for the vehicle, generating a vehicle-occupied trajectory representative of first points in an environment occupied by the vehicle if the vehicle were to implement the first safety procedure at that time; based at least in part on an object state of an object at the time and a second safety procedure for the object, generating an object-occupied trajectory representative of second points in the environment occupied by the object if the object were to implement the second safety procedure at that time; Determining that at least one of the first points is contained in the second points; Calculating a first safety potential associated with the vehicle implementing the first safety procedure and the object implementing the second safety procedure; Calculating a second safety potential associated with the vehicle implementing an alternative procedure different from the first safety procedure at the time and the object implementing the second safety procedure; and Performing the alternative procedure based at least in part on a determination that, relative to the first safety potential, the second safety potential is associated with a lower probability of causing a collision between the vehicle and the object. [19] The method of claim 18, wherein calculating the second safety potential comprises performing a fault analysis to determine safety potentials associated with a plurality of procedures for the vehicle, including the alternative procedure. [20] The method of claim 18, further comprising: based at least in part on the vehicle state of the vehicle at the time and the alternative procedure for the vehicle, generating an alternative vehicle-occupied trajectory representative of third points in the environment occupied by the vehicle if the vehicle were to perform the alternative procedure at the time, wherein calculating the second safety potential comprises determining whether at least one of the third points is included in the second points.

Images