Patent ID: 12214801

DETAILED DESCRIPTION

The following describes the technology of this disclosure within the context of an autonomous vehicle for example purposes only. As described herein, the technology described herein is not limited to an autonomous vehicle and can be implemented within other robotic and computing systems. With reference now toFIGS.1-9, example embodiments of the present disclosure will be discussed in further detail.

Autonomous systems (e.g., autonomous vehicles, subject vehicles) are applications in which comprehensive testing is often desirable before real-world deployment. As the performance of autonomous vehicles (e.g., subject vehicles) improves for foreseeable scenarios, it becomes important to test the autonomous vehicles in unlikely scenarios, such as where the autonomous vehicle may be challenged or ultimately fail one or more performance criteria. However, exhaustively searching over all possible scenarios can be computationally unfeasible, because there are exponentially numerous scenario variations due to the combinatorial number of possible lane topologies, actor configurations, trajectories, velocity profiles, appearance of actors and background, and so on.

In conventional systems, comprehensive testing can rely on human expertise to create an initial scenario set, where each scenario contains just a few actors (e.g., vehicles that interact with the AV's planned path) with specified initial locations and trajectories. Scenario variations are then programmatically created by varying the location and velocity profiles of the actors. These scenarios only evaluate simple interactions with the AV and do not test complex multi-actor interactions, such as lane-merging, unprotected left-turns in dense traffic scenes, or other interactions that the AV may encounter. Moreover, human involvement makes the conventional testing process time-consuming and difficult to scale. Furthermore, manual design can result in missing testing configurations that identify unexpected failure modes, as it can be difficult to assess coverage.

Additionally, conventional testing systems may not be able to generate adversarial scenarios when the environment includes actors that are hard to identify due to occlusion, or the trajectory plans for the actors are difficult to localize and forecast. Such issues in the perception and motion forecasting modules of the autonomy system can generate compounding errors that ultimately cause planning failures.

In contrast, embodiments of the present disclosure can generate complex and realistic traffic scenarios at scale for the AV testing system. In some implementations, the testing system can generate worst-case scenarios as a black box adversarial attack that can test any LiDAR-based autonomy system. The testing system can determine adversarial perturbations with respect to physically feasible changes in actor behavior, since such perturbations provide insight into the different types of driving situations that are challenging.

According to some embodiments, the testing system leverages real world traffic scenarios, which can be obtained from standard self-driving datasets, and optimize the trajectories of the actors to increase the risk of an autonomy system failure. Additionally, as the perturbation modifies the trajectories of the actors, the sensor data can be adjusted to accurately reflect the new state (e.g., velocity, location) of the actors. The testing system can use a high-fidelity LiDAR simulator that modifies the sensor data accordingly, while also taking into account occlusions. After running the black-box autonomy system with modified sensor data as input, the testing system generates the planned trajectory based on the modified sensor data. An adversarial module of the testing system evaluates the updated scenario to determine an adversarial value. The adversarial module captures multiple performance factors such as collisions, violations in traffic rules, uncomfortable driving behaviors, and so on. The testing system demonstrates flexibility and scalability by generating thousands of adversarial scenarios for a wide range of modern autonomy systems. Finally, the testing system can leverage generated traffic scenarios in training and further improve the performance of autonomy systems.

The autonomy systems can be separated into a plurality of sequential subtasks, such as object detection (e.g., perception system), motion forecasting (e.g., prediction system), and motion planning (e.g., motion planning system). In conventional systems, these sequential subtasks are developed separately, and thus cannot correct compounding errors. In contrast, the testing system described herein can evaluate a wide range of autonomy systems, including modular and end-to-end interpretable ones. For example, end-to-end self-driving can use deeper network architectures, more informative sensor inputs, and scalable learning methods. Additionally, interpretable neural motion planners can maintain modularity and interpretability while enabling end-to-end learning.

With regards to generating simulation scenarios, the testing system can generate a scenario parameterization space to optimize and identify critical scenario parameters using a search algorithm, and test (e.g., evaluate) the autonomous system using an evaluation setting. The testing system can represent the behavior of actors as kinematic bicycle-model trajectories that allow for physical feasibility and fine-grained behavior control. The search algorithm utilized to identify scenarios that cause autonomy failure include, but is not limited to, policy gradient, Bayesian optimization, evolutionary algorithms, and variants of Monte Carlo sampling. The testing system can build a general scenario generation algorithm, benchmark a wide variety of black-box search algorithms, and provide insight into which search algorithms are effective. The testing system includes an end-to-end adversarial scenario generation system that takes into account failures of the full autonomy stack. Additionally, the testing system scales to datasets with diverse traffic patterns and map configurations.

FIG.1depicts a block diagram of an example operational scenario100according to example implementations of the present disclosure. The operational scenario100includes an autonomous platform105and an environment110. The environment110can be external to the autonomous platform105. The autonomous platform105, for example, can operate within the environment110. The environment110can include an indoor environment (e.g., within one or more facilities, etc.) or an outdoor environment. An outdoor environment, for example, can include one or more areas in the outside world such as, for example, one or more rural areas (e.g., with one or more rural travel ways, etc.), one or more urban areas (e.g., with one or more city travel ways, highways, etc.), one or more suburban areas (e.g., with one or more suburban travel ways, etc.), etc. An indoor environment, for example, can include environments enclosed by a structure such as a building (e.g., a service depot, manufacturing facility, etc.).

The environment110can include one or more dynamic object(s)130(e.g., actors, simulated objects, real-world objects, etc.). The dynamic object(s)130can include any number of moveable objects such as, for example, one or more pedestrians, animals, vehicles, etc. The dynamic object(s)130can move within the environment according to one or more trajectories135. Although trajectories135are depicted as emanating from dynamic object(s)130, it is also to be understood that relative motion within the environment110can include one or more trajectories of the autonomous platform105itself. For instance, aspects of the present disclosure relate to the generation of trajectories via a joint prediction/planning framework, and those trajectories can, in various implementations, take into account trajectories135of the dynamic object(s)130and/or one or more trajectories of the autonomous platform105itself.

The autonomous platform105can include one or more sensor(s)115,120. The one or more sensors115,120can be configured to generate or store data descriptive of the environment110(e.g., one or more static or dynamic objects therein, etc.). The sensor(s)115,120can include one or more LiDAR systems, one or more Radio Detection and Ranging (RADAR) systems, one or more cameras (e.g., visible spectrum cameras or infrared cameras, etc.), one or more sonar systems, one or more motion sensors, or other types of image capture devices or sensors. The sensor(s)115,120can include multiple sensors of different types. For instance, the sensor(s)115,120can include one or more first sensor(s)115and one or more second sensor(s)120. The first sensor(s)115can include a different type of sensor than the second sensor(s)120. By way of example, the first sensor(s)115can include one or more imaging device(s) (e.g., cameras, etc.), whereas the second sensor(s)120can include one or more depth measuring device(s) (e.g., LiDAR device, etc.).

The autonomous platform105can include any type of platform configured to operate within the environment110. For example, the autonomous platform105can include one or more different type(s) of vehicle(s) configured to perceive and operate within the environment110. The vehicles, for example, can include one or more autonomous vehicle(s) such as, for example, one or more autonomous trucks. By way of example, the autonomous platform105can include an autonomous truck, including an autonomous tractor coupled to a cargo trailer. In addition, or alternatively, the autonomous platform105can include any other type of vehicle such as one or more aerial vehicles, ground-based vehicles, water-based vehicles, space-based vehicles, etc.

FIG.2depicts an example system overview200of the autonomous platform as an autonomous vehicle (e.g., subject vehicle) according to example implementations of the present disclosure. The system overview200can be of an autonomous system. More particularly,FIG.2illustrates a vehicle205including various systems and devices configured to control the operation of the vehicle205. For example, the vehicle205(e.g., subject vehicle) can include an onboard vehicle computing system210(e.g., located on or within the autonomous vehicle, etc.) that is configured to operate the vehicle205. For example, the vehicle computing system210can represent or be an autonomous vehicle control system configured to perform the operations and functions described herein for joint prediction/planning of trajectories. Generally, the vehicle computing system210can obtain sensor data255from sensor(s)235(e.g., sensor(s)115,120ofFIG.1, etc.) onboard the vehicle205, attempt to comprehend the vehicle's surrounding environment by performing various processing techniques on the sensor data255, and generate an appropriate motion plan through the vehicle's surrounding environment (e.g., environment110ofFIG.1, etc.).

The vehicle205incorporating the vehicle computing system210can be various types of vehicles. For instance, the vehicle205can be an autonomous vehicle. The vehicle205can be a ground-based autonomous vehicle (e.g., car, truck, bus, etc.). The vehicle205can be an air-based autonomous vehicle (e.g., airplane, helicopter, etc.). The vehicle205can be a lightweight electric vehicle (e.g., bicycle, scooter, etc.). The vehicle205can be another type of vehicle (e.g., watercraft, etc.). The vehicle205can drive, navigate, operate, etc. with minimal or no interaction from a human operator (e.g., driver, pilot, etc.). In some implementations, a human operator can be omitted from the vehicle205(or also omitted from remote control of the vehicle205). In some implementations, a human operator can be included in the vehicle205.

The vehicle205can be configured to operate in a plurality of operating modes. The vehicle205can be configured to operate in a fully autonomous (e.g., self-driving, etc.) operating mode in which the vehicle205is controllable without user input (e.g., can drive and navigate with no input from a human operator present in the vehicle205or remote from the vehicle205, etc.). The vehicle205can operate in a semi-autonomous operating mode in which the vehicle205can operate with some input from a human operator present in the vehicle205(or a human operator that is remote from the vehicle205). The vehicle205can enter into a manual operating mode in which the vehicle205is fully controllable by a human operator (e.g., human driver, pilot, etc.) and can be prohibited or disabled (e.g., temporary, permanently, etc.) from performing autonomous navigation (e.g., autonomous driving, flying, etc.). The vehicle205can be configured to operate in other modes such as, for example, park or sleep modes (e.g., for use between tasks/actions such as waiting to provide a vehicle service, recharging, etc.). In some implementations, the vehicle205can implement vehicle operating assistance technology (e.g., collision mitigation system, power assist steering, etc.), for example, to help assist the human operator of the vehicle205(e.g., while in a manual mode, etc.).

To help maintain and switch between operating modes, the vehicle computing system210can store data indicative of the operating modes of the vehicle205in a memory onboard the vehicle205. For example, the operating modes can be defined by an operating mode data structure (e.g., rule, list, table, etc.) that indicates one or more operating parameters for the vehicle205, while in the particular operating mode. For example, an operating mode data structure can indicate that the vehicle205is to autonomously plan its motion when in the fully autonomous operating mode. The vehicle computing system210can access the memory when implementing an operating mode.

The operating mode of the vehicle205can be adjusted in a variety of manners. For example, the operating mode of the vehicle205can be selected remotely, off-board the vehicle205. For example, a remote computing system (e.g., of a vehicle provider, fleet manager, or service entity associated with the vehicle205, etc.) can communicate data to the vehicle205instructing the vehicle205to enter into, exit from, maintain, etc. an operating mode. By way of example, such data can instruct the vehicle205to enter into the fully autonomous operating mode.

In some implementations, the operating mode of the vehicle205can be set onboard or near the vehicle205. For example, the vehicle computing system210can automatically determine when and where the vehicle205is to enter, change, maintain, etc. a particular operating mode (e.g., without user input, etc.). Additionally, or alternatively, the operating mode of the vehicle205can be manually selected through one or more interfaces located onboard the vehicle205(e.g., key switch, button, etc.) or associated with a computing device within a certain distance to the vehicle205(e.g., a tablet operated by authorized personnel located near the vehicle205and connected by wire or within a wireless communication range, etc.). In some implementations, the operating mode of the vehicle205can be adjusted by manipulating a series of interfaces in a particular order to cause the vehicle205to enter into a particular operating mode.

The operations computing system290A can include multiple components for performing various operations and functions. For example, the operations computing system290A can be configured to monitor and communicate with the vehicle205or its users. This can include overseeing the vehicle205and/or coordinating a vehicle service provided by the vehicle205(e.g., cargo delivery service, passenger transport, etc.). To do so, the operations computing system290A can communicate with the one or more remote computing system(s)290B or the vehicle205through one or more communications network(s) including the communications network(s)220. The communications network(s)220can send or receive signals (e.g., electronic signals, etc.) or data (e.g., data from a computing device, etc.) and include any combination of various wired (e.g., twisted pair cable, etc.) or wireless communication mechanisms (e.g., cellular, wireless, satellite, microwave, and radio frequency, etc.) or any desired network topology (or topologies). For example, the communications network220can include a local area network (e.g., intranet, etc.), wide area network (e.g., the Internet, etc.), wireless LAN network (e.g., through Wi-Fi, etc.), cellular network, a SATCOM network, VHF network, a HF network, a WiMAX based network, or any other suitable communications network (or combination thereof) for transmitting data to or from the vehicle205.

Each of the one or more remote computing system(s)290B or the operations computing system290A can include one or more processors and one or more memory devices. The one or more memory devices can be used to store instructions that when executed by the one or more processors of the one or more remote computing system(s)290B or operations computing system290A cause the one or more processors to perform operations or functions including operations or functions associated with the vehicle205including sending or receiving data or signals to or from the vehicle205, monitoring the state of the vehicle205, or controlling the vehicle205. The one or more remote computing system(s)290B can communicate (e.g., exchange data or signals, etc.) with one or more devices including the operations computing system290A and the vehicle205through the communications network(s)220.

The one or more remote computing system(s)290B can include one or more computing devices such as, for example, one or more devices associated with a service entity (e.g., coordinating and managing a vehicle service), one or more operator devices associated with one or more vehicle providers (e.g., providing vehicles for use by the service entity, etc.), user devices associated with one or more vehicle passengers, developer devices associated with one or more vehicle developers (e.g., a laptop/tablet computer configured to access computer software of the vehicle computing system210, etc.), or other devices. One or more of the devices can receive input instructions from a user or exchange signals or data with an item or other computing device or computing system (e.g., the operations computing system290A, etc.). Further, the one or more remote computing system(s)290B can be used to determine or modify one or more states of the vehicle205including a location (e.g., a latitude and longitude, etc.), a velocity, an acceleration, a trajectory, a heading, or a path of the vehicle205based in part on signals or data exchanged with the vehicle205. In some implementations, the operations computing system290A can include the one or more remote computing system(s)290B.

The vehicle computing system210can include one or more computing devices located onboard the vehicle205. For example, the computing device(s) can be located on or within the vehicle205. The computing device(s) can include various components for performing various operations and functions. For instance, the computing device(s) can include one or more processors and one or more tangible, non-transitory, computer readable media (e.g., memory devices, etc.). The one or more tangible, non-transitory, computer readable media can store instructions that when executed by the one or more processors cause the vehicle205(e.g., its computing system, one or more processors, etc.) to perform operations and functions, such as those described herein for collecting and processing sensor data, performing autonomy functions, predicting object trajectories and generating vehicle motion trajectories (e.g., using a joint prediction/planning framework according to example aspects of the present disclosure), controlling the vehicle205, communicating with other computing systems, etc.

The vehicle205can include a communications system215configured to allow the vehicle computing system210(and its computing device(s)) to communicate with other computing devices. The communications system215can include any suitable components for interfacing with one or more network(s)220, including, for example, transmitters, receivers, ports, controllers, antennas, or other suitable components that can help facilitate communication. In some implementations, the communications system215can include a plurality of components (e.g., antennas, transmitters, or receivers, etc.) that allow it to implement and utilize multiple-input, multiple-output (MIMO) technology and communication techniques. The vehicle computing system210can use the communications system215to communicate with one or more computing devices that are remote from the vehicle205over the communication network(s)220(e.g., through one or more wireless signal connections, etc.).

As shown inFIG.2, the vehicle computing system210can include the one or more sensors235, the autonomy computing system240, the vehicle interface245, the one or more vehicle control systems250, and other systems, as described herein. One or more of these systems can be configured to communicate with one another through one or more communication channels. The communication channel(s) can include one or more data buses (e.g., controller area network (CAN), etc.), on-board diagnostics connector (e.g., OBD-II, etc.), or a combination of wired or wireless communication links. The onboard systems can send or receive data, messages, signals, etc. amongst one another through the communication channel(s).

In some implementations, the sensor(s)235can include one or more LiDAR sensor(s). The sensor(s)235can be configured to generate point data descriptive of a portion of a three-hundred-and-sixty-degree view of the surrounding environment. In some instances, the sensor(s)235can be configured to generate simulated sensor data, such as simulated three-dimensional LiDAR point cloud data. In some implementations, one or more sensors235for capturing depth information can be fixed to a rotational device in order to rotate the sensor(s) about an axis. The sensor(s)235can be rotated about the axis while capturing data in interval sector packets descriptive of different portions of a three-hundred-and-sixty-degree view of a surrounding environment of the vehicle205. In some implementations, one or more sensors235for capturing depth information can be solid state.

In some implementations, the sensor(s)235can include at least two different types of sensor(s). For instance, the sensor(s)235can include at least one first sensor (e.g., the first sensor(s)115, etc.) and at least one second sensor (e.g., the second sensor(s)120, etc.). The at least one first sensor can be a different type of sensor than the at least one second sensor. For example, the at least one first sensor can include one or more image capturing device(s) (e.g., one or more cameras, RGB cameras, etc.). In addition, or alternatively, the at least one second sensor can include one or more depth capturing device(s) (e.g., LiDAR sensor, etc.). The at least two different types of sensor(s) can obtain multi-modal sensor data indicative of one or more static or dynamic objects within an environment of the vehicle205.

The sensor(s)235can be configured to acquire sensor data255or generate sensor data255(e.g., simulated sensor data). The sensor(s)235can be external sensors configured to acquire external sensor data. This can include sensor data associated with the surrounding environment of the vehicle205. The surrounding environment of the vehicle205can include/be represented in the field of view of the sensor(s)235. For instance, the sensor(s)235can acquire image or other data of the environment outside of the vehicle205and within a range or field of view of one or more of the sensor(s)235. This can include different types of sensor data acquired by the sensor(s)235such as, for example, data from one or more LiDAR systems, one or more RADAR systems, one or more cameras (e.g., visible spectrum cameras, infrared cameras, etc.), one or more motion sensors, one or more audio sensors (e.g., microphones, etc.), or other types of imaging capture devices or sensors. The sensor data255can include image data (e.g., 2D camera data, video data, etc.), RADAR data, LiDAR data (e.g., 3D point cloud data, etc.), audio data, or other types of data. In addition, or alternatively, the sensor data255can include simulated image data (e.g., simulated 2D camera data, simulated video data, etc.), simulated RADAR data, simulated LiDAR data (e.g., simulated 3D point cloud data, etc.), simulated audio data, or other types of simulated data. The one or more sensors can be located on various parts of the vehicle205including a front side, rear side, left side, right side, top, or bottom of the vehicle205. The vehicle205can also include other sensors configured to acquire data associated with the vehicle205itself. For example, the vehicle205can include inertial measurement unit(s), wheel odometry devices, or other sensors.

The sensor data255can be indicative of one or more objects within the surrounding environment of the vehicle205. The object(s) can include, for example, vehicles, pedestrians, bicycles, or other objects. The object(s) can be located in front of, to the rear of, to the side of, above, below the vehicle205, etc. The sensor data255can be indicative of locations associated with the object(s) within the surrounding environment of the vehicle205at one or more times. The object(s) can be static objects (e.g., not in motion, etc.) or dynamic objects, such as other objects (e.g., in motion or likely to be in motion, etc.) in the vehicle's environment, such as people, animals, machines, vehicles, etc. The sensor data255can also be indicative of the static background of the environment. The sensor(s)235can provide the sensor data255to the autonomy computing system240, the remote computing device(s)290B, or the operations computing system290A.

In addition to the sensor data255, the autonomy computing system240can obtain map data260. The map data260can provide detailed information about the surrounding environment of the vehicle205or the geographic area in which the vehicle205was, is, or will be located. For example, the map data260can provide information regarding: the identity and location of different roadways, road segments, buildings, or other items or objects (e.g., lampposts, crosswalks or curb, etc.); the location and directions of traffic lanes (e.g., the location and direction of a parking lane, a turning lane, a bicycle lane, or other lanes within a particular roadway or other travel way or one or more boundary markings associated therewith, etc.); traffic control data (e.g., the location and instructions of signage, traffic lights, or other traffic control devices, etc.); obstruction information (e.g., temporary or permanent blockages, etc.); event data (e.g., road closures/traffic rule alterations due to parades, concerts, sporting events, etc.); nominal vehicle path data (e.g., indicate of an ideal vehicle path such as along the center of a certain lane, etc.); or any other map data that provides information that assists the vehicle computing system210in processing, analyzing, and perceiving its surrounding environment and its relationship thereto. In some implementations, the map data260can include high-definition map data. In some implementations, the map data260can include sparse map data indicative of a limited number of environmental features (e.g., lane boundaries, etc.). In some implementations, the map data can be limited to geographic area(s) or operating domains in which the vehicle205(or autonomous vehicles generally) can travel (e.g., due to legal/regulatory constraints, autonomy capabilities, or other factors, etc.).

The vehicle205can include a positioning system265. The positioning system265can determine a current position of the vehicle205. This can help the vehicle205localize itself within its environment. The positioning system265can be any device or circuitry for analyzing the position of the vehicle205. For example, the positioning system265can determine position by using one or more of inertial sensors (e.g., inertial measurement unit(s), etc.), a satellite positioning system, based on IP address, by using triangulation or proximity to network access points or other network components (e.g., cellular towers, Wi-Fi access points, etc.) or other suitable techniques. The position of the vehicle205can be used by various systems of the vehicle computing system210or provided to a remote computing system. For example, the map data260can provide the vehicle205relative positions of the elements of a surrounding environment of the vehicle205. The vehicle205can identify its position within the surrounding environment (e.g., across six axes, etc.) based at least in part on the map data260. For example, the vehicle computing system210can process the sensor data255(e.g., LiDAR data, camera data, etc.) to match it to a map of the surrounding environment to get an understanding of the vehicle's position within that environment. Data indicative of the vehicle's position can be stored, communicated to, or otherwise obtained by the autonomy computing system240.

The autonomy computing system240can perform various functions for autonomously operating the vehicle205. For example, the autonomy computing system240can perform the following functions: perception270A, prediction/forecasting270B, and motion planning270C. For example, the autonomy computing system240can obtain the sensor data255through the sensor(s)235, process the sensor data255(or other data) to perceive its surrounding environment, predict the motion of objects within the surrounding environment, and generate an appropriate motion plan through such surrounding environment. In some implementations, these autonomy functions can be performed by one or more sub-systems such as, for example, a perception system, a prediction/forecasting system, a motion planning system, or other systems that cooperate to perceive the surrounding environment of the vehicle205and determine a motion plan for controlling the motion of the vehicle205accordingly. In some implementations, one or more of the perception, prediction, or motion planning functions270A,270B,270C can be performed by (or combined into) the same system or through shared computing resources. In some implementations, one or more of these functions can be performed through different sub-systems. As further described herein, the autonomy computing system240can communicate with the one or more vehicle control systems250to operate the vehicle205according to the motion plan (e.g., through the vehicle interface245, etc.).

For example, in some implementations, the autonomy computing system240can contain an interactive planning system270for joint planning/prediction according to example aspects of the present disclosure. Interactive planning system270can be included as an addition or complement to one or more traditional planning system(s). For instance, in some implementations, the interactive planning system270can implement prediction and motion planning functions270B and270C, while optionally one or more other planning systems can implement other prediction and motion planning functions (e.g., noninteractive functions). In some implementations, prediction and motion planning functions270B and270C can be implemented jointly to provide for interactive motion planning (e.g., motion planning for vehicle205that accounts for predicted interactions of other objects (e.g., objects130ofFIG.1) with the motion plans, etc.). In some implementations, however, interactive planning system270can be configured to provide noninteractive planning (e.g., optionally in addition to interactive planning). In some implementations, interactive planning system270can be configured with variable interactivity, such that the output(s) of interactive planning system270can be adjusted to fully interactive planning, fully noninteractive planning, and one or more configurations therebetween (e.g., interactive planning aspects in a weighted combination with noninteractive planning aspects, etc.).

The vehicle computing system210(e.g., the autonomy computing system240, etc.) can identify one or more objects that are within the surrounding environment of the vehicle205based at least in part on the sensor data255or the map data260. The objects perceived within the surrounding environment can be those within the field of view of the sensor(s)235or predicted to be occluded from the sensor(s)235. This can include object(s) not in motion or not predicted to move (static objects) or object(s) in motion or predicted to be in motion (dynamic objects/actors). The vehicle computing system210(e.g., performing the perception function270A, using a perception system, etc.) can process the sensor data255, the map data260, etc. to obtain perception data275A. The vehicle computing system210can generate perception data275A that is indicative of one or more states (e.g., current or past state(s), etc.) of one or more objects that are within a surrounding environment of the vehicle205. For example, the perception data275A for each object can describe (e.g., for a given time, time period, etc.) an estimate of the object's: current or past location (also referred to as position); current or past speed/velocity; current or past acceleration; current or past heading; current or past orientation; size/footprint (e.g., as represented by a bounding shape, object highlighting, etc.); class (e.g., pedestrian class vs. vehicle class vs. bicycle class, etc.), the uncertainties associated therewith, or other state information. The vehicle computing system210can utilize one or more algorithms or machine-learned model(s) that are configured to identify object(s) based at least in part on the sensor data255. This can include, for example, one or more neural networks trained to identify object(s) within the surrounding environment of the vehicle205and the state data associated therewith. The perception data275A can be utilized for the prediction function270B of the autonomy computing system240.

The vehicle computing system210can be configured to predict a motion of the object(s) within the surrounding environment of the vehicle205. For instance, the vehicle computing system210can generate prediction data275B associated with such object(s). The prediction data275B can be indicative of one or more predicted future locations of each respective object. For example, the prediction function270B can determine a predicted motion trajectory along which a respective object is predicted to travel over time. A predicted motion trajectory can be indicative of a path that the object is predicted to traverse and an associated timing with which the object is predicted to travel along the path. The predicted path can include or be made up of a plurality of waypoints. In some implementations, the prediction data275B can be indicative of the speed or acceleration at which the respective object is predicted to travel along its associated predicted motion trajectory. The vehicle computing system210can utilize one or more algorithms and one or more machine-learned model(s) that are configured to predict the future motion of object(s) based at least in part on the sensor data255, the perception data275A, map data260, or other data. This can include, for example, one or more neural networks trained to predict the motion of the object(s) within the surrounding environment of the vehicle205based at least in part on the past or current state(s) of those objects as well as the environment in which the objects are located (e.g., the lane boundary in which it is travelling, etc.). The prediction data275B can be utilized for the motion planning function270C of the autonomy computing system240, such as in a joint planning/prediction technique implemented by interactive planning system270.

The vehicle computing system210can determine a motion plan for the vehicle205based at least in part on the perception data275A, the prediction data275B, or other data. For example, the vehicle computing system210can generate motion planning data275C indicative of a motion plan. The motion plan can include vehicle actions (e.g., speed(s), acceleration(s), other actions, etc.) with respect to one or more of the objects within the surrounding environment of the vehicle205as well as the objects' predicted movements. The motion plan can include one or more vehicle motion trajectories that indicate a path for the vehicle205to follow. A vehicle motion trajectory can be of a certain length or time range. A vehicle motion trajectory can be defined by one or more waypoints (with associated coordinates). The waypoint(s) can be future location(s) for the vehicle205. The planned vehicle motion trajectories can indicate the path the vehicle205is to follow as it traverses a route from one location to another. Thus, the vehicle computing system210can take into account a route/route data when performing the motion planning function270C.

The vehicle computing system210can implement (e.g., via interactive planning system270) an optimization algorithm, machine-learned model, etc. that considers cost data associated with a vehicle action as well as other objectives (e.g., cost functions, such as cost functions based at least in part on dynamic objects, speed limits, traffic lights, etc.), if any, to determine optimized variables that make up the motion plan. The vehicle computing system210can determine that the vehicle205can perform a certain action (e.g., pass an object, etc.) without increasing the potential risk to the vehicle205or violating any traffic laws (e.g., speed limits, lane boundaries, signage, etc.). For instance, the vehicle computing system210can evaluate the predicted motion trajectories of one or more objects during its cost data analysis to help determine an optimized vehicle trajectory through the surrounding environment. The motion planning function270C can generate cost data associated with such trajectories. In some implementations, one or more of the predicted motion trajectories or perceived objects may not ultimately change the motion of the vehicle205(e.g., due to an overriding factor, etc.). In some implementations, the motion plan can define the vehicle's motion such that the vehicle205avoids the object(s), reduces speed to give more leeway to one or more of the object(s), proceeds cautiously, performs a stopping action, passes an object, queues behind/in front of an object, etc.

The vehicle computing system210can be configured to continuously update the vehicle's motion plan and corresponding planned vehicle motion trajectories. For example, in some implementations, the vehicle computing system210can generate new motion planning data275C (e.g., motion plan(s)) for the vehicle205(e.g., multiple times per second, etc.). Each new motion plan can describe a motion of the vehicle205over the next planning period (e.g., waypoint(s)/locations(s) over the next several seconds, etc.). Moreover, a motion plan can include a planned vehicle motion trajectory. The motion trajectory can be indicative of the future planned location(s), waypoint(s), heading, velocity, acceleration, etc. In some implementations, the vehicle computing system210can continuously operate to revise or otherwise generate a short-term motion plan based on the currently available data. Once the optimization planner has identified the optimal motion plan (or some other iterative break occurs), the optimal motion plan (and the planned motion trajectory) can be selected and executed by the vehicle205.

The vehicle computing system210can cause the vehicle205to initiate a motion control in accordance with at least a portion of the motion planning data275C. A motion control can be an operation, action, etc. that is associated with controlling the motion of the vehicle205. For instance, the motion planning data275C can be provided to the vehicle control system(s)250of the vehicle205. The vehicle control system(s)250can be associated with a vehicle interface245that is configured to implement a motion plan. The vehicle interface245can serve as an interface/conduit between the autonomy computing system240and the vehicle control systems250of the vehicle205and any electrical/mechanical controllers associated therewith. The vehicle interface245can, for example, translate a motion plan into instructions for the appropriate vehicle control component (e.g., acceleration control, brake control, steering control, etc.). By way of example, the vehicle interface245can translate a determined motion plan into instructions to adjust the steering of the vehicle205by a certain number of degrees, apply a certain magnitude of braking force, increase/decrease speed, etc. The vehicle interface245can help facilitate the responsible vehicle control (e.g., braking control system, steering control system, acceleration control system, etc.) to execute the instructions and implement a motion plan (e.g., by sending control signal(s), making the translated plan available, etc.). This can allow the vehicle205to autonomously travel within the vehicle's surrounding environment.

The vehicle computing system210can store other types of data. For example, an indication, record, or other data indicative of the state of the vehicle (e.g., its location, motion trajectory, health information, etc.), the state of one or more users (e.g., passengers, operators, etc.) of the vehicle, or the state of an environment including one or more objects (e.g., the physical dimensions or appearance of the one or more objects, locations, predicted motion, etc.) can be stored locally in one or more memory devices of the vehicle205. Additionally, the vehicle205can communicate data indicative of the state of the vehicle, the state of one or more passengers of the vehicle, or the state of an environment to a computing system that is remote from the vehicle205, which can store such information in one or more memories remote from the vehicle205. Moreover, the vehicle205can provide any of the data created or store onboard the vehicle205to another vehicle.

The vehicle computing system210can include or otherwise be in communication with the one or more vehicle user devices280. For example, the vehicle computing system210can include, or otherwise be in communication with, one or more user devices with one or more display devices located onboard the vehicle205. A display device (e.g., screen of a tablet, laptop, smartphone, etc.) can be viewable by a user of the vehicle205that is located in the front of the vehicle205(e.g., driver's seat, front passenger seat, etc.). Additionally, or alternatively, a display device can be viewable by a user of the vehicle205that is located in the rear of the vehicle205(e.g., a back passenger seat, etc.). The user device(s) associated with the display devices can be any type of user device such as, for example, a tablet, mobile phone, laptop, etc. The vehicle user device(s)280can be configured to function as human-machine interfaces. For example, the vehicle user device(s)280can be configured to obtain user input, which can then be utilized by the vehicle computing system210or another computing system (e.g., a remote computing system, etc.). For example, a user (e.g., a passenger for transportation service, a vehicle operator, etc.) of the vehicle205can provide user input to adjust a destination location of the vehicle205. The vehicle computing system210or another computing system can update the destination location of the vehicle205and the route associated therewith to reflect the change indicated by the user input.

As described herein, with reference to the remaining figures, the autonomy computing system240can utilize one or more machine-learned models to perform the perception270A, prediction270B, or motion planning270C functions. The machine-learned model(s) can be previously trained through one or more machine-learned techniques. The machine-learned models can be previously trained by the one or more remote computing system(s)290B, the operations computing system290A, or any other device (e.g., remote servers, training computing systems, etc.) remote from or onboard the vehicle205. For example, the one or more machine-learned models can be learned by a training computing system over training data stored in a training database. The training data can include, for example, sequential sensor data indicative of an environment (and objects/features within) at different timesteps. In some implementations, the training data can include a plurality of environments previously recorded by the autonomous vehicle with one or more objects, static object(s) or dynamic object(s).

To help improve the performance of an autonomous platform, such as an autonomous vehicle ofFIG.2, the technology of the present disclosure generally provides for implementing an interactive planning system270. In particular, example aspects of the present disclosure provide for a structured deep model (e.g., a structured machine-learned model) that uses a set of learnable costs across a set of future (e.g., possible) object trajectories. In some instances, the set of learnable costs can induce a joint probability distribution over the set of future object trajectories (e.g., a distribution of probabilities for each of the set of future object trajectories, such as a set of probabilities for each of the set of future object trajectories conditioned on the vehicle motion trajectory of the autonomous vehicle). In this manner, for example, the interactive planning system270can jointly predict object motion (e.g., using the probability information) and plan vehicle motion (e.g., according to the costs).

In some implementations, an interactive planning system270can implement interactive planning or noninteractive planning, as well as combinations thereof. For example,FIG.3Aillustrates an ego-actor, such as autonomous vehicle300(e.g., subject vehicle), traversing a lane of a roadway. It might be desired for the autonomous vehicle300to change lanes to move into the other lane302(e.g., by following one or more vehicle motion trajectories304). However, the autonomous vehicle300is sharing the roadway with objects312,314, and316(e.g., other actors). And it can be predicted (e.g., by prediction function270B) that object312will continue moving forward in lane302along object trajectory320and maintain the same distance behind object314, which may not leave sufficient room for autonomous vehicle300to maneuver into lane302while meeting other constraints (e.g., buffer space constraints, etc.). Based on this prediction, for example, the autonomous vehicle300can choose one of the motion trajectories304that does not interfere with the object312on the object trajectory320(e.g., as illustrated inFIG.3B).

In some scenarios, the other objects312,314, and316, absent an external factor, might never move in such a way as to permit the autonomous vehicle300to ever obtain sufficient space (e.g., between objects312and314) to change lanes. For instance, object312might never have any interaction with any motion of autonomous vehicle300(e.g., never cooperatively adapt to the motion of the autonomous vehicle300). But in some scenarios, the object312might interact with a motion of the autonomous vehicle300in such a way as to open up space in the lane302.

FIG.4depicts an overview of an example testing system400of the autonomous system (e.g., robotic platform102ofFIG.1, system overview200ofFIG.2, vehicle computing system210ofFIG.2) according to example implementations of the present disclosure. In some implementations, the testing system400can obtain sensor data255, map data260, and data from positioning system265ofFIG.2to generate a perturbed trajectory for an actor, generate simulated sensor data, generate an updated trajectory for the subject vehicle and evaluate an adversarial loss function for the autonomous system as described inFIGS.5-8.

According to some embodiments, the testing system400includes a perturbed actor trajectory generator410, a simulated sensor data generator420, an autonomous vehicle control system430, and an adversarial loss function evaluator440. The testing system400generates testing data for an autonomous vehicle. In some instances, the testing system obtains sensor data descriptive of a traffic scenario. The traffic scenario can include a subject vehicle and one or more actors in an environment of the subject vehicle.

In some implementations, the perturbed actor trajectory generator410generates a perturbed trajectory412for an actor based on selected perturbation values416. The testing system400can define a perturbation search space and select the perturbation values416from the defined perturbation search space414. The perturbed trajectory412can be generated based on the selected perturbation values416. In some implementations, the selected perturbation values416can be selected based in part on the historical observations450. The historical observations450can include previously selected perturbation values and previously calculated adversarial loss values. In some instances, the actor that the perturbed trajectory412is generated for is a first actor of the one or more actors in the environment.

The testing system400can identify one or more actors that are within the surrounding environment of the subject vehicle (e.g., vehicle205inFIG.2) based at least in part on the sensor data255that is generated by sensor(s)235. The perturbed trajectory412for an actor can be determined based on the sensor data255, the map data260, and data obtained from the positioning system265. The actors perceived within the surrounding environment can be those within the field of view of the sensor(s)235or predicted to be occluded from the sensor(s)235. This can include actors not in motion or not predicted to move (static actors) or actors in motion or predicted to be in motion (dynamic actors). The testing system400, using the perturbed actor trajectory generator410, can process the sensor data255, the map data260, and other data to obtain the perturbed trajectory412for an actor.

The perturbed actor trajectory generator410can generate the perturbed trajectory412for an actor that is indicative of one or more states of the actor within a surrounding environment of the subject vehicle. For example, the perturbed trajectory412can describe for a given period of time an estimate of the actor's: current or past location (also referred to as position); current or past speed/velocity; current or past acceleration; current or past heading; current or past orientation; size/footprint (e.g., as represented by a bounding shape, object highlighting, etc.); class (e.g., pedestrian class vs. vehicle class vs. bicycle class, etc.), the uncertainties associated therewith, or other state information. The perturbed trajectory412can be utilized for functions of the simulated sensor data generator420, the autonomous vehicle control system430, and the adversarial loss function evaluator440. For example, the perturbed trajectory412can be an input to the simulated sensor data generator420, the autonomous vehicle control system430, and the adversarial loss function evaluator440in order to determine simulated sensor data422, an updated trajectory432for a subject vehicle, and an adversarial loss value444.

Additionally, in some implementations, the simulated sensor data generator420generates simulated sensor data422. The simulated sensor data422includes data descriptive of the perturbed trajectory412for the first actor in the environment.

Moreover, in some implementations, the testing system400provides the simulated sensor data422as input to the autonomous vehicle control system430. The autonomous vehicle control system430is configured to process the simulated sensor data422to generate an updated trajectory432for the subject vehicle in the environment.

The updated trajectory432for the subject vehicle can be indicative of one or more states (e.g., current, or past state(s)) of the subject vehicle (e.g., vehicle205inFIG.2). For example, the updated trajectory432can describe for a given period of time an estimate of the subject vehicle's: current or past location (also referred to as position); current or past speed/velocity; current or past acceleration; current or past heading; current or past orientation; size/footprint (e.g., as represented by a bounding shape, object highlighting, etc.); class (e.g., pedestrian class vs. vehicle class vs. bicycle class, etc.), the uncertainties associated therewith, or other state information. The updated trajectory432for a subject vehicle can be utilized for functions of the simulated sensor data generator420and the adversarial loss function evaluator440. For example, the updated trajectory432for a subject vehicle can be an input to the simulated sensor data generator420and the adversarial loss function evaluator440in order to determine simulated sensor data422and an adversarial loss value444.

The autonomous vehicle control system430can be configured to generate an updated trajectory432of the subject vehicle. The updated trajectory432can be indicative of one or more predicted future locations of the subject vehicle. The motion path of the subject vehicle can be based on the updated trajectory432. For example, the autonomous vehicle control system430can determine the updated trajectory432along which the subject vehicle is predicted to travel over time. The updated trajectory432can be indicative of a path that the subject vehicle is predicted to traverse and an associated timing with which the subject vehicle is predicted to travel along the path. The predicted path can include or be made up of a plurality of way points. In some implementations, the updated trajectory432can be indicative of the speed or acceleration at which the subject vehicle is predicted to travel along its associated updated trajectory432.

Furthermore, in some implementations, the adversarial loss function evaluator440evaluates an adversarial loss function442based on the updated trajectory432for the subject vehicle to generate an adversarial loss value444. Method800ofFIG.8describes techniques for calculating the adversarial loss value444.

Subsequently, the selected perturbation values416and the adversarial loss value can be added to the set of historical observations. As previously mentioned, the selected perturbation values416can be selected based in part on the historical observations450. In some implementations, the simulated sensor data422and the updated trajectory432for the subject vehicle can also be added to the set of historical observations.

The testing system400can utilize one or more algorithms or machine-learned model(s), such as a trajectory refinement model, sensor data generator model, and an adversarial loss function model, that are configured to determine trajectories of objects (e.g., actors, subject vehicle), evaluate loss functions for an autonomous system, and generate simulated sensor data. This can include, for example, one or more neural networks trained to identify actors within the surrounding environment of the vehicle205, determine a trajectory for an object, generate simulated sensor data, evaluate (e.g., optimize) an adversarial loss function for an autonomous vehicle, and other data associated therewith.

The machine-learned models (e.g., trajectory refinement model, sensor data generator model, and an adversarial loss function model) can be previously trained by the one or more remote computing system(s)290B, the operations computing system290A, or any other device (e.g., remote servers, training computing systems, etc.) remote from or onboard the vehicle205. For example, the machine-learned models can be learned by a training computing system (e.g., the operations computing system290A, etc.) over training data stored in a training database. The training data can include sequential multi-modal sensor data indicative of a plurality of environments at different interval of time. In some implementations, the training data can include sensor data255, perturbed trajectory412for an actor, simulated sensor data422, updated trajectory432for a subject vehicle, adversarial loss value444, perception data275A, prediction data275B, and motion plan data275C.

FIG.5Adepicts an adversarial scenario generation process500implemented by a testing system (e.g., testing system400ofFIG.4) of the autonomous system (e.g., robotic platform102ofFIG.1, system overview200ofFIG.2, vehicle computing system210ofFIG.2) according to example implementations of the present disclosure.FIG.5Adepicts elements performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure.FIG.5Ais described with reference to elements/terms described with respect to other systems and figures for exemplary illustrated purposes and is not meant to be limiting. One or more portions of the operations and phases described inFIG.5Acan be performed additionally, or alternatively, by other systems.

According to some embodiments, the adversarial scenario generation process500perturbs the maneuvers of interactive actors in an existing scenario with adversarial behaviors that cause realistic autonomy system failures. Given an existing scenario and its original sensor data (e.g., sensor data255), a computing system (e.g., vehicle computing system210ofFIG.2, testing system400ofFIG.4) perturbs the scenario by generating a perturbed trajectory for an actor, and determines the interaction of the subject vehicle (e.g., vehicle205ofFIG.2) to the simulated sensor data (e.g., simulated sensor data422ofFIG.4) based on the new scene configuration. Subsequently, the computing system evaluates the autonomy system (e.g., subject vehicle) on the modified scenario, computes an adversarial objective (e.g., adversarial loss value444ofFIG.4), and updates the proposed perturbation using a search algorithm.

In some implementations, an object of the computing system (e.g., vehicle computing system210ofFIG.2, testing system400inFIG.4) is to generate realistic, challenging scenarios that can cause autonomy system failure. The objective can be framed as a black box adversarial attack that exercises every component of an autonomy system (e.g., system200ofFIG.2), including object detection (e.g., perception270A ofFIG.2), motion forecasting (e.g., prediction270B ofFIG.2), and motion planning (e.g., motion planning270C ofFIG.2). The computing system can examine a defined space of realistic perturbations in actor motions of an existing scenario. Additionally, the computing system can update the sensor data (e.g., sensor data255, simulated sensor data422ofFIG.4) that the subject vehicle (e.g., vehicle205ofFIG.2) observes. Moreover, the computing system can evaluate the autonomy system based on the updated sensor data.

As depicted inFIG.5A, at505the computing system obtains point cloud data from sensors (e.g., sensor(s)235ofFIG.2). Additionally, at510, the computing system perturbs the motion trajectories of the actors in an existing scenario to simulate an adversarial behavior. Moreover, at515, the computing system utilizes a LiDAR simulation to generate simulated point cloud data520. The simulated point cloud data520can include a sequence of LiDAR point clouds that reflect changes in the location of one or more actors. With the simulated point cloud data520, the computing system uses the autonomy system525and generates the planned motion path535(e.g., motion plan data275C ofFIG.2, updated trajectory432ofFIG.4) of the subject vehicle. Subsequently, the computing system evaluates the planned motion path535with a proposed adversarial objective to generate a cost measure at530. Furthermore, at540, the computing system can adjust the scenario perturbation to be more challenging.

As described in the following paragraphs, the example adversarial scenario generation process500ofFIG.5Adepicts elements performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure.FIG.5Ais described with reference to elements/terms described with respect to other systems and figures for exemplary illustrated purposes and is not meant to be limiting. One or more portions of the operations and phases described inFIG.5Acan be performed additionally, or alternatively, by other systems.

In the problem setup phase, the testing system (e.g., testing system400ofFIG.4) defines the autonomy system and an attack formulation. In the modeling adversarial behaviors phase, the testing system parameterizes the adversarial actors' behaviors. In the realistic LiDAR simulation phase, the testing system conducts realistic LiDAR simulation to generate new LiDAR sweeps. In the adversarial scenario search phase, the testing system generates worst-case scenarios by benchmarking the adversarial objective and the black-box optimization algorithms.

Problem Setup Phase

According to some embodiments, the problem setup phase can be initiated by defining={v0, v1, . . . , vM} to be the set of vehicles that compose the scene, where v0denotes the subject vehicle (e.g., self-driving vehicle (SDV)), M is the number of other vehicles. The objective of a self-driving system can be to find the best planned trajectory τ0* according to a cost function C that maneuvers around the scene, given the available sensor data inputs x, as described in Equation 1.

τ0*⁡(x)=argminτ0⁢⁢⁢𝒞⁡(τ0,x)(Equation⁢⁢1)

In Equation 1, τ0is the subject vehicle's planned trajectory. As x consists of raw sensor data (e.g., LiDAR point clouds, sensor data255ofFIG.2), high-definition maps (e.g., map data260), and other relevant information (e.g., previous states of the subject vehicle, traffic light states), the minimization of Equation 1 represents optimization for the full autonomy system (e.g., system200), not just a planning module (e.g., motion planning270C).

In some instances, one of the goals of the testing system is to increase the risk of the subject vehicle by perturbing the behaviors of other actors in a physically plausible manner for an existing traffic scenario. Without loss of generality, the testing system considers perturbing a single actor in the following discussion for brevity, but we apply the testing system for multi-actor perturbations in experiments.

The testing system can characterize the behavior of an adversary by the trajectory τadv(e.g., perturbed trajectory412for an actor) that an actor will take in the future. As the perturbed actor's trajectory τadvdiffers from its original behavior in the sensor data, the actor's position and the generated occlusions will change, as later described inFIG.5B. Therefore, the testing system simulates the new LiDAR data given the adversary trajectory τadvand subject vehicle trajectory τsdvto evaluate the system described in Equation 1. The generation of point clouds in the perturbed traffic scene is described by Equation 2.
xadv=ƒ(x,τadv,τsdv)  (Equation 2)

In Equation 2, ƒ(⋅) denotes the realistic LiDAR simulation, which is described in the realistic LiDAR simulation phase, for perturbed input xadvgiven the adversary's trajectory and original sensor data sequence x.

The testing system then defines an adversarial objective τadvwhich is optimized (e.g., maximized) to generate scenarios as described in Equation 3.

τadv*=argmax⁢τadv⁢⁢ℒadv⁡(τ0*,xadv),(Equation⁢⁢3)

In Equation 3, τ0*=τ0*(xadv) is the optimal planned trajectory of the subject vehicle under simulated scene xadv. Additional discussion of the design of the adversarial lossadvis deferred to the adversarial scenario search phase.

Modeling Adversarial Behaviors Phase

To produce physically feasible actor behaviors, the testing system parameterizes the trajectory τadv={st}t=0Tas a sequence of kinematic bicycle model states st={xt, yt, θt, vt, κt, at} in the next T timesteps. Here (x, y) is the center position of the perturbed actor, θ is the heading, v and a are the forward velocity and acceleration, and κ is the vehicle path's curvature. Candidate adversary trajectories can be generated by perturbing the change of curvature {dot over (κ)}tand acceleration values atwithin set bounds at different timesteps and using the kinematic bicycle model to compute the other states.

Moreover, to enlarge the space of sampled adversarial behaviors, the testing system also allows the perturbation of initial states (x0, y0, θ0, v0) within set bounds. In summary, the perturbation space can be depicted as δ={Δs0, (a0, {dot over (κ)}t|t=0), . . . , (aT-1, {dot over (κ)}t|t=T-1)}.

To increase the perturbed trajectory's plausibility, the testing system ensures the subject vehicle does not collide with other actors or the original expert trajectory of the subject vehicle. In practice, the testing system accomplishes this by first performing rejection sampling to create a set of physically feasible trajectoriesadvand then projecting the trajectory generated by δ on to the physically feasible set, measured by L2distance. The search space can be low-dimensional and conducive to query-based black box optimization, while still allowing for fine-grained actor motion control.

Realistic LiDAR Simulation Phase

FIG.5Bdepicts an exemplary LiDAR simulation550for scenario perturbations according to example implementations of the present disclosure. Given a scenario perturbation on the motions of actors, the previously recorded LiDAR data can be modified, by the testing system, to accurately reflect the updated scene configuration. In the removing actors operation560, the testing system can remove one or more original actor LiDAR observations. In the adding actors operation580, the testing system can replace one or more original actor LiDAR observations with simulated actor LiDAR observations at the perturbed locations, while ensuring sensor realism. The example depicted inFIG.5Bperturbs all actors left by a predetermined distance (e.g., five meters).FIG.5Bdepicts operations performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure.FIG.5Bis described with reference to elements/terms described with respect to other systems and figures for exemplary illustrated purposes and is not meant to be limiting. One or more portions of the operations and phases described inFIG.5Bcan be performed additionally, or alternatively, by other systems.

Given an initial traffic scenario and the corresponding adversarial perturbation to the behaviors of the actors, the testing system modifies the existing real LiDAR sweeps to reflect the perturbation. The testing system can adopt a high-fidelity LiDAR simulator, which leverages real world data to generate realistic background meshes and dynamic object assets, and then applies physics-based raycasting and machine learning to generate realistic LiDAR point clouds (e.g., simulated sensor data422). Given a modified scene configuration, the testing system can use the LiDAR simulator to render a simulated point cloud (e.g., simulated sensor data422), and then update the real LiDAR sweep with the modified regions. The testing system can choose to update the sensor data for modified regions only, instead of generating the full sweep to speed up the query function ƒ in Equation 2. Specifically, the testing system can cache the simulated background LiDAR, as the subject vehicle trajectory is fixed during the actor perturbation. The sensor perturbation is illustrated inFIG.5B.

The testing system can modify the LiDAR sensor data to reflect that the scenario perturbation is non-trivial, as the LiDAR's sensing characteristics cause specific visibility artifacts that can exist in the generated scene to be realistic and physically accurate. The testing system can perform two operations for sensor simulation for modified scenarios. The removing actors operation560removes the existing benign actors' LiDAR point cloud and fills the LiDAR shadow that has been created. The adding actors operation580inserts the adversarial actors' LiDAR point cloud, while accounting for occlusion.

Removing Actors Operation

Given an original LiDAR point cloud562, the testing system first removes the points within the bounding boxes574of perturbed actors and simulates background points564using a background mesh of a LiDAR simulator. The testing system then converts the simulated and real LiDAR sweeps into a range image, in order to identify the specific rays missing in the real LiDAR sweep566that exist in the simulated LiDAR. By taking the element-wise minimum ray distance between the range images, the testing system can merge the LiDAR point clouds. The testing system generates the merged point cloud568after one or more actors is removed, where the first pattern570corresponds to the simulated points and the second pattern572corresponds to the original real points.

Adding Actors Operation

Once the testing system has removed the selected actors (e.g., bounding boxes574) from the LiDAR sweep, the testing system can update the LiDAR with the actors at their new locations. The testing system can first render the simulated LiDAR for the actors at their new locations582using a vehicle asset bank of the LiDAR simulator. The testing system can then generate a real LiDAR point cloud with the added actors584. However, when a LiDAR ray hits an object, the remaining path of the ray becomes occluded, creating a LiDAR shadow. Similar to the actor removal process, the testing system can create range images of the simulated and real LiDAR, and merge the LiDAR point clouds, thereby removing the LiDAR points of the now-occluded regions586and obtaining the final modified LiDAR sweep588. The generated scenes can be realistic and match the desired perturbation in the motions of the actors, as described inFIG.5B.

Adversarial Scenario Search Phase

Given that the aim is to create a general adversarial scenario generation framework, the testing system considers the autonomy system as a black box, where the testing system accesses the evaluation scores (e.g., adversarial loss value444) through limited queries. The testing system can find the perturbation that optimizes the subject vehicle's planned trajectory cost. In this phase, the testing system utilizes an adversarial objective to optimize in order to produce worst-case scenarios.

Adversarial Objective:

To induce autonomy system failures, the testing system can use a combination of costs as an adversarial loss function.FIG.7further describes how the adversarial loss function can utilize these costs to calculate the adversarial loss value. These costs can be similar to costs in Equation 1 that the testing system tries to optimize (e.g., minimize). The testing system can first include lIL, an imitation-learning based cost that encourages the subject vehicle's output plan to deviate from the recorded human trajectory in the original scenario. The testing system can compute the imitation-learning based cost as a smooth l1distance between output trajectory τ0* and the ground-truth for the entire scenario horizon. The testing system can also compute a cumulative collision cost lcoltthat encourages the perturbation to cause the subject vehicle to collide with other actors in the scene. Finally, the testing system can add a comfort cost cst(xadv, τ0*) that encourages the output plan τ0* to have lane violations and be dangerous (e.g., high accelerations and jerk) at each timestep t. The full adversarial loss is defined as:

ℒadv=minτ0⁢[lIL+∑t⁢lcolt+∑t⁢cst⁡(xadv,τ0*)]

By using multiple different costs, it allows the testing system to identify different types of autonomy system failures, such as unnatural trajectories, collisions, and hard braking.

Search Algorithms

The testing system is a framework that can use any black-box search algorithm to identify autonomy system failures. The search algorithm attempts to find desirable scenarios by optimizing (e.g., maximizing) the adversarial objectiveadvin Equation 2. The search algorithm queries the autonomy system with a candidate perturbation τadvto obtain a query pair (τadv,adv) and maintains a historyof past query pairs to generate the next candidate perturbation. The testing system can use a wide variety of black-box search algorithms including: (1) Bayesian optimization; (2) genetic algorithms; (3) random search; and (4) gradient estimation methods. Specifically, the Bayesian optimization algorithm maintains a surrogate model and selects the next candidate based on the acquisition function and current model states. For the genetic algorithms, a group of candidate trajectories are evolved to optimize the objective and the best candidate is preserved at each iteration. For the random search algorithm, the perturbations sampled from a pre-defined orthonormal basis are added or subtracted to original input iteratively. Another branch of query-based black-box search algorithms estimate the gradient through the target model. Furthermore, the gradient estimation methods optimize the expectation of the objective under one search distribution and further leverage temporal information to improve the query efficiency.

Overall Adversarial Scenario Generation Algorithm

According to some embodiments, the framework of testing system can be described using Algorithm 1. Given an initial traffic scene, the testing system can pick the actors to be perturbed using heuristics, such as the closest reachable actors, and then sample physically plausible trajectoriesadvto ensure that the perturbations remain in this set. The testing system then obtains the perturbation δ(k)at iteration k based on historical observationsusing a selected black-box search algorithm (Line 5 of Algorithm 1). The testing system can roll out the kinematics bicycle model states with initial state s0and the perturbation δ(k), and project onto the feasible setadvto obtain the adversarial trajectories for the perturbed actors (Line 6 of Algorithm 1). After that, the testing system can update the sensor data accordingly (Line 7 of Algorithm 1) and evaluate the full autonomy system on generated scenarios to computeadv(Lines 8 and 9 of Algorithm 1). Finally, after running the procedure for N iterations, the testing system can obtain the adversarial behaviors of perturbed actors as well as corresponding simulated LiDAR data.

Algorithm 1 Generating Adversarial ScenariosRequire: Sensory input x, initial state s0of the perturbedactor, adversarial objectiveadv, number of queries N.1:Pick the perturbed actor vadvheuristically2:Generate physically plausible trajectories setadv3:Initialize observation set= Ø4:for k = 1, . . . , N do5:Select δ(k)based on black-box algorithms and his-torical observations.6:τadv(k)=[BICYCLE (S0, δ(k))]7:xadv(k)= f(x, τadv(k), τsdv)8:Run the autonomy system and obtain the optimalSDV plan τ0(k)= τ0*(xadv(k))9:Calculate the adversarial loss of the optimal plan:adv(k)=adv(τ0(k),xadv(k))10:Update observation set=∪ {(τadv(k),adv(k))}11:end for12:τadv* = arg maxτadv(k),k∈[N]adv(k)

According to some embodiments, the testing system can use an adversarial framework to generate worst-case scenarios for modern autonomy systems. The testing system can identify physically plausible failure cases that impose risks to the full autonomy stack by simulating the sensor data based on the perturbed behaviors. Furthermore, the testing system can leverage these scenarios in training to further improve the robustness and performance of the autonomy system.

FIG.6depicts a flowchart of a method600for generating testing data for an autonomous vehicle, according to aspects of the present disclosure. One or more portion(s) of the method600can be implemented by a computing system that includes one or more computing devices such as, for example, the computing systems described with reference to the other figures (e.g., autonomous platform105, vehicle computing system210, operations computing system(s)290A, remote computing system(s)290B, testing system400). Each respective portion of the method600can be performed by any (or any combination) of one or more computing devices. Moreover, one or more portion(s) of the method600can be implemented as an algorithm on the hardware components of the device(s) described herein (e.g.,FIGS.1-2,4,9), for example, to train a machine learning model to select a perturbation value, generate a perturbed trajectory412for an actor, generate simulated sensor data422, generate an updated trajectory432for a subject vehicle, and calculate an adversarial loss value444as described inFIGS.4,7, and8.

FIG.6depicts elements performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure.FIG.6is described with reference to elements/terms described with respect to other systems and figures for exemplary illustrated purposes and is not meant to be limiting. One or more portions of method600can be performed additionally, or alternatively, by other systems.

At610, a computing system obtains sensor data descriptive of a traffic scenario including a subject vehicle and one or more actors in an environment of the subject vehicle. In some instances, the computing system can be the autonomous platform105, vehicle computing system210, operations computing system(s)290A, remote computing system(s)290B, or testing system400. Additionally, the subject vehicle can be the autonomous platform105or vehicle205. Moreover, the one or more actors can be the one or more dynamic object(s)130(e.g., actors, simulated objects, real-world objects, etc.). Furthermore, the sensor data obtained at610can be sensor data255that is obtained from sensor(s)235.

In some instances, the sensor data includes real-world sensor data previously collected by one or more physical sensors in the environment.

In some instances, the computing system can select one or more perturbation values from a defined perturbation search space. The defined perturbation search space can be determined or generated by the computing system. In some instances, the perturbation search space can include initial state values and a set of change in curvatures and acceleration values over a number of timesteps.

At620, the computing system generates a perturbed trajectory for a first actor of the one or more actors in the environment based on one or more perturbation values. The one or more perturbation values can be selected from a defined perturbation search space. Method800ofFIG.8describes an exemplary method for selecting the one or more perturbation values from a defined perturbation search space. In some instances, the perturbed trajectory generated at620can be the perturbed trajectory412for an actor that is generated by the perturbed actor trajectory generator410as described inFIG.4.

In some instances, the perturbed trajectory for the first actor is generated at620by the computing system first generating a defined perturbation search space. The perturbation search space can include initial state values and a set of change in curvatures and acceleration values over a number of timesteps. Additionally, the computing system can select one or more perturbation values from the defined perturbation search space. Moreover, the computing system can perform a black-box optimization technique to select the one or more perturbation values from the defined perturbation search space. For example, the black-box optimization technique can include one of the following: Bayesian optimization; a genetic algorithm; random search; or a gradient estimation method. Moreover, the perturbed trajectory for the first actor that is generated at620can be based on the selection of the one or more perturbation values. In other example implementations, the computing system can employ a reinforcement learning agent to select the perturbation values from the perturbation search space. The reinforcement learning agent can be trained (e.g., updated) based on the adversarial loss function. Some example reinforcement learning agents can be or include a neural network such as a recurrent neural network (e.g., long short-term memory neural network).

In some instances, the perturbed trajectory for the first actor is generated at620by first creating a set of physically feasible trajectories for the first actor. Additionally, the computing system can generate an initial perturbed trajectory for the first actor based on the one or more perturbation values. Moreover, the computing system can project the initial perturbed trajectory onto the set of physically feasible trajectories to generate the perturbed trajectory.

In some instances, the perturbed trajectory for the first actor is generated at620by ensuring that the perturbed trajectory avoids collision with: (i) one or more existing trajectories of one or more other actors in the environment; or (ii) an initial trajectory for the subject vehicle in the environment.

In some instances, the perturbed trajectory generated at620can be parameterized as a series of kinematic bicycle model states. In some instances, the computing system can select a closest reachable actor as the first actor.

At630, the computing system generates simulated sensor data including data descriptive of the perturbed trajectory for the first actor in the environment. In some instances, the simulated sensor data generated at630can be the simulated sensor data422that is generated by the simulated sensor data generator420as described inFIG.4.

At640, the computing system provides the simulated sensor data as input to an autonomous vehicle control system configured to process the simulated sensor data to generate an updated trajectory for the subject vehicle in the environment. In some instances, the updated trajectory for the subject vehicle generated at640can be the updated trajectory432for a subject vehicle that is generated by the autonomous vehicle control system430as described inFIG.4.

In some instances, the autonomous vehicle control system can include one of the following: an end-to-end imitation learning system; a neural motion planner; a jointly learnable behavior and trajectory planning system; or a perceive, predict, and plan system.

In some instances, the autonomous vehicle control system is a simulated AV control system. The simulated AV control can control an AV in a simulated environment and not a physical real-life environment.

At650, the computing system evaluates an adversarial loss function based on the updated trajectory for the subject vehicle to generate an adversarial loss value. In some instances, the adversarial loss value generated at650can be the adversarial loss value444that is generated by the adversarial loss function evaluator440using the adversarial loss function442as described inFIG.4.

In some instances, the autonomous vehicle control system (e.g., autonomous vehicle control system430) described at640can include one or more machine-learned models. Additionally, method600can further include updating one or more values of one or more parameters of the one or more machine-learned models based on the adversarial loss function generated at650.

In some instances, the adversarial loss function includes one or more of the following: (1) an imitation-learning cost term that encourages the updated trajectory to deviate from an original trajectory of the subject vehicle in the traffic scenario; (2) a cumulative collision cost term that encourages the perturbation values to cause the subject vehicle to collide with the one or more actors; and (3) a comfort cost term that encourages the updated trajectory to have lane violations, high acceleration, or jerk.

In some instances, the perturbed trajectory for the first actor is generated at620by the computing system selecting the one or more perturbation values from a defined perturbation search space based at least in part on a set of historical observations associated with previously selected perturbation values. Additionally, the method further includes adding the one or more perturbation values that can be selected at620and the adversarial loss value that is evaluated at650to the set of historical observations, and then repeating operations610-640.

In some instances, the perturbed trajectory for the first actor is generated at620by the computing system selecting the one or more perturbation values with an objective of optimizing an adversarial loss value provided by the adversarial loss function that is evaluated at650.

In some instances, the sensor data obtained at610includes light detection and ranging (LiDAR) data, and the simulated sensor data generated at630includes simulated LiDAR data. The computing system can remove LiDAR points within a bounding box associated with the first actor. Additionally, the computing system can simulate new background LiDAR points after removing the LiDAR points within the bounding box. Moreover, the computing system can insert simulated LiDAR points based on the perturbed trajectory for the first actor. Furthermore, the computing system can remove LiDAR points included within a synthesized LiDAR shadow for one or more occluded regions based on the perturbed trajectory for the first actor.

The method600can be further modified by one or more portion(s) of method700inFIG.7. For example, one or more portions of method700can be performed in addition to the method600.FIG.7depicts a flowchart of a method700for determining an adversarial loss value using an adversarial loss function, according to aspects of the present disclosure. One or more portion(s) of the method700can be implemented by a computing system that includes one or more computing devices such as, for example, the computing systems described with reference to the other figures (e.g., autonomous platform105, vehicle computing system210, operations computing system(s)290A, remote computing system(s)290B, testing system400). Each respective portion of the method700can be performed by any (or any combination) of one or more computing devices. Moreover, one or more portion(s) of the method700can be implemented as an algorithm on the hardware components of the device(s) described herein (e.g.,FIGS.1-2,4,9), for example, using the adversarial loss value or the adversarial loss function to train a machine learning model to generate a perturbed trajectory412for an actor, simulated sensor data422, and an updated trajectory432for a subject vehicle as described inFIGS.4,6, and8.

Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure.FIG.7is described with reference to elements/terms described with respect to other systems and figures for exemplary illustrated purposes and is not meant to be limiting. One or more portions of method700can be performed additionally, or alternatively, by other systems.

At705, a computing system evaluates the adversarial loss function used in operation650of method600by using an imitation-learning cost term that encourages the updated trajectory to deviate from an original trajectory of the subject vehicle in the traffic scenario. In some instances, the adversarial loss function evaluator440uses the imitation learning cost term at705as part of the adversarial loss function442in order to determine the adversarial loss value444as described inFIG.4.

At710, the computing system evaluates the adversarial loss function used in operation650of method600by using a cumulative collision cost term that encourages the perturbation values to cause the subject vehicle to collide with the one or more actors. In some instances, the adversarial loss function evaluator440uses the cumulative collision cost term at710as part of the adversarial loss function442in order to determine the adversarial loss value444as described inFIG.4.

At715, the computing system evaluates the adversarial loss function used in operation650of method600by using a comfort cost term that encourages the updated trajectory to have lane violations, high acceleration, and/or jerk. In some instances, the adversarial loss function evaluator440uses the comfort cost term at715as part of the adversarial loss function442in order to determine the adversarial loss value444as described inFIG.4.

At715, the computing system calculates the adversarial loss value based on the evaluation at705,710, and/or715. In some instances, the adversarial loss function evaluator440uses the imitation learning cost term at705, the cumulative collision cost term at710, and the comfort cost term at715as part of the adversarial loss function442in order to calculate the adversarial loss value444as described inFIG.4.

In some implementations, the adversarial loss value444calculated at715can be added to the historical observations450ofFIG.4. Additionally, the one or more perturbation values selected at620of method600can be selected based on the historical observations450, which includes previously calculated adversarial loss values. Moreover, the one or more perturbation values are selected at620of method600with an objective of optimizing an adversarial loss value provided by the adversarial loss function.

The method600can be further modified by one or more portion(s) of method800inFIG.8. For example, one or more portions of method800can be performed in addition to the method600and method700.FIG.8depicts a flowchart of a method800for selecting perturbation values bases on a set of historical observations, according to aspects of the present disclosure. One or more portion(s) of the method800can be implemented by a computing system that includes one or more computing devices such as, for example, the computing systems described with reference to the other figures (e.g., autonomous platform105, vehicle computing system210, operations computing system(s)290A, remote computing system(s)290B, testing system400). Each respective portion of the method800can be performed by any (or any combination) of one or more computing devices. Moreover, one or more portion(s) of the method800can be implemented as an algorithm on the hardware components of the device(s) described herein (e.g.,FIGS.1-2,4,9), for example, using historical observations associated with previously selected perturbation values to train a machine learning model to select perturbation values associated with a perturbed trajectory412for an actor, generate simulated sensor data422, an generate an updated trajectory432for a subject vehicle, calculate an adversarial loss value as described inFIGS.4,6, and7.

At805, the computing system selects the one or more perturbation values from a defined perturbation search space based at least in part on a set of historical observations associated with previously selected perturbation values. In some instances, the one or more perturbation values selected at805can be the one or more perturbation values that are used in operation620to generate the perturbed trajectory for the first actor as described inFIG.6. In some instances, the historical observations described at805can be the historical observations450as described inFIG.4.

At810, the computing system adds the one or more perturbation values and the adversarial loss value to the set of historical observations. Operations650ofFIG.6and method700ofFIG.7describe techniques for calculating the adversarial loss value. In some instances, the one or more perturbation values and the adversarial loss value added at810can be the selected perturbation values416and the adversarial loss value444described inFIG.4. Additionally, the set of historical observations described at810can be the historical observations450as described inFIG.4.

At815, the computing system can repeat operations610,620,630, and640of method600as described inFIG.6. For example, once the selected perturbation values and the calculated adversarial loss value is added to the historical observations, then the computing system can repeat method600to generate another updated trajectory for the subject vehicle. Additionally, a new adversarial loss value can be calculated with an objective of optimizing (e.g., maximizing) the adversarial loss value provided by the adversarial loss function.

In some implementations, method800can further include operation820, where the computing system optimizes (e.g., maximizes) the adversarial value provided by the adversarial loss function by repeating operations805,810, and815to generate a worst-case scenario for an autonomy system.

Techniques described inFIG.8identify physically plausible failure cases that impose risks to a full autonomy stack by simulating the sensor data based on the perturbed behaviors. The computing system can generate failure cases at scale for a wide range of systems. Additionally, the computing system can leverage these scenarios in training to further improve the robustness and performance of the autonomy system.

FIG.9depicts a block diagram of an example computing system900according to example embodiments of the present disclosure. The example computing system900includes a computing system1100and a machine learning computing system1200that are communicatively coupled over one or more networks1300.

In some implementations, the computing system1100can perform one or more observation tasks such as, for example, by obtaining sensor data (e.g., object data, traffic data, multi-modal sensor data) associated with an environment. In some implementations, the computing system1100can be included in a robotic platform. For example, the computing system1100can be on-board an autonomous vehicle. In other implementations, the computing system1100is not located on-board a robotic platform. The computing system1100can include one or more distinct physical computing devices1105.

The computing system1100(or one or more computing device(s)1105thereof) can include one or more processors1110and a memory1115. The one or more processors1110can be any suitable processing device (e.g., a processor core, a microprocessor, an ASIC, a FPGA, a controller, a microcontroller, etc.) and can be one processor or a plurality of processors that are operatively connected. The memory1115can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, one or more memory devices, flash memory devices, etc., and combinations thereof.

The memory1115can store information that can be accessed by the one or more processors1110. For instance, the memory1115(e.g., one or more non-transitory computer-readable storage mediums, memory devices) can store data1120that can be obtained, received, accessed, written, manipulated, created, or stored. The data1120can include, for instance, object data, traffic element data, hybrid graph data, image data, LiDAR data, multi-modal sensor data, models, intermediate and other scene representations, or any other data or information described herein. In some implementations, the computing system1100can obtain data from one or more memory device(s) that are remote from the computing system1100.

The memory1115can also store computer-readable instructions1125that can be executed by the one or more processors1110. The instructions1125can be software written in any suitable programming language or can be implemented in hardware. Additionally, or alternatively, the instructions1125can be executed in logically or virtually separate threads on processor(s)1110.

For example, the memory1115can store instructions1125that when executed by the one or more processors1110cause the one or more processors1110(the computing system1100) to perform any of the operations, functions, or methods/processes described herein, including, for example, obtain sensor data, generate an object observation, generate a path observation, determine an object size, generate an initial object trajectory, generate a refined object trajectory, determine a motion plan, implement a motion plan, update a machine-learned model, and so on.

According to an aspect of the present disclosure, the computing system1100can store or include one or more machine-learned models1135. As examples, the machine-learned models1135can be or can otherwise include various machine-learned models such as, for example, inpainting networks, generative adversarial networks, neural networks (e.g., deep neural networks), support vector machines, decision trees, ensemble models, k-nearest neighbors models, Bayesian networks, or other types of models including linear models or non-linear models. Example neural networks include feed-forward neural networks, recurrent neural networks (e.g., long short-term memory recurrent neural networks), convolutional neural networks, or other forms of neural networks.

In some implementations, the computing system1100can receive the one or more machine-learned models1135from the machine learning computing system1200over network(s)1300and can store the one or more machine-learned models1135in the memory1115. The computing system1100can then use or otherwise implement the one or more machine-learned models1135(e.g., by processor(s)1110). In particular, the computing system1100can implement the machine-learned model(s)1135to obtain sensor data, generate an object observation, generate a path observation, determine an object size, generate an initial object trajectory, generate a refined object trajectory, determine a motion plan, implement a motion plan, update a machine-learned model, and so on.

The machine learning computing system1200can include one or more computing devices1205. The machine learning computing system1200can include one or more processors1210and a memory1215. The one or more processors1210can be any suitable processing device (e.g., a processor core, a microprocessor, an ASIC, a FPGA, a controller, a microcontroller, etc.) and can be one processor or a plurality of processors that are operatively connected. The memory1215can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, one or more memory devices, flash memory devices, etc., and combinations thereof.

The memory1215can store information that can be accessed by the one or more processors1210. For instance, the memory1215(e.g., one or more non-transitory computer-readable storage mediums, memory devices) can store data1220that can be obtained, received, accessed, written, manipulated, created, or stored. The data1220can include, for instance, object data, traffic element data, hybrid graph data, multi-modal sensor data, intermediate representations, scene representations, simulation data, data associated with models, or any other data or information described herein. In some implementations, the machine learning computing system1200can obtain data from one or more memory device(s) that are remote from the machine learning computing system1200.

The memory1215can also store computer-readable instructions1225that can be executed by the one or more processors1210. The instructions1225can be software written in any suitable programming language or can be implemented in hardware. Additionally, or alternatively, the instructions1225can be executed in logically or virtually separate threads on processor(s)1210.

For example, the memory1215can store instructions1225that when executed by the one or more processors1210cause the one or more processors1210(the computing system) to perform any of the operations or functions described herein, including, for example, obtaining sensor data, generating an object observation, generating a path observation, determining an object size, generating an initial object trajectory, generating a refined object trajectory, determining a motion plan, implementing a motion plan, updating a machine-learned model, and so on.

In some implementations, the machine learning computing system1200includes one or more server computing devices. If the machine learning computing system1200includes multiple server computing devices, such server computing devices can operate according to various computing architectures, including, for example, sequential computing architectures, parallel computing architectures, or some combination thereof.

In addition, or alternatively to the model(s)1235at the computing system1100, the machine learning computing system1200can include one or more machine-learned models1235. As examples, the machine-learned models1235can be or can otherwise include various machine-learned models such as, for example, inpainting networks, generative adversarial networks, neural networks (e.g., deep neural networks), support vector machines, decision trees, ensemble models, k-nearest neighbors models, Bayesian networks, or other types of models including linear models or non-linear models. Example neural networks include feed-forward neural networks, recurrent neural networks (e.g., long short-term memory recurrent neural networks), convolutional neural networks, or other forms of neural networks.

In some implementations, the machine learning computing system1200or the computing system1100can train the machine-learned models1135or1235through use of a model trainer1240. The model trainer1240can train the machine-learned models1135or1235using one or more training or learning algorithms. One example training technique is backwards propagation of errors. In some implementations, the model trainer1240can perform supervised training techniques using a set of labeled training data. In other implementations, the model trainer1240can perform unsupervised training techniques using a set of unlabeled training data. The model trainer1240can perform a number of generalization techniques to improve the generalization capability of the models being trained. Generalization techniques include weight decays, dropouts, or other techniques.

In particular, the model trainer1240can train a machine-learned model1135or1235based on a set of training data1245. The training data1245can include, for example, object data, traffic element data, hybrid graph data, data associated with the interaction prediction model, data associated with the graph neural network data, labeled sequential multi-modal sensor data indicative of a plurality of environments at different timesteps, and so on. In some implementations, the training data can include a plurality of environments previously recorded by the autonomous vehicle with dynamic objects removed. The model trainer1240can be implemented in hardware, firmware, or software controlling one or more processors.

The computing system1100and the machine learning computing system1200can each include a communication interface1130and1250, respectively. The communication interfaces1130/1250can be used to communicate with one or more systems or devices, including systems or devices that are remotely located from the computing system1100and the machine learning computing system1200. A communication interface1130/1250can include any circuits, components, software, etc. for communicating with one or more networks (e.g.,1300). In some implementations, a communication interface1130/1250can include, for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software, or hardware for communicating data.

The network(s)1300can be any type of network or combination of networks that allows for communication between devices. In some embodiments, the network(s) can include one or more of a local area network, wide area network, the Internet, secure network, cellular network, mesh network, peer-to-peer communication link or some combination thereof and can include any number of wired or wireless links. Communication over the network(s)1300can be accomplished, for instance, through a network interface using any type of protocol, protection scheme, encoding, format, packaging, etc.

FIG.9illustrates one example computing system900that can be used to implement the present disclosure. Other computing systems can be used as well. For example, in some implementations, the computing system1100can include the model trainer1240and the training data1245. In such implementations, the machine-learned models1235can be both trained and used locally at the computing system1100. As another example, in some implementations, the computing system1100is not connected to other computing systems.

In addition, components illustrated or discussed as being included in one of the computing systems1100or1200can instead be included in another of the computing systems1100or1200. Such configurations can be implemented without deviating from the scope of the present disclosure. The use of computer-based systems allows for a great variety of possible configurations, combinations, and divisions of tasks and functionality between and among components. Computer-implemented operations can be performed on a single component or across multiple components. Computer-implemented tasks or operations can be performed sequentially or in parallel. Data and instructions can be stored in a single memory device or across multiple memory devices. Computing tasks discussed herein as being performed at computing device(s) remote from the autonomous vehicle can instead be performed at the autonomous vehicle (e.g., via the vehicle computing system), or vice versa. Such configurations can be implemented without deviating from the scope of the present disclosure. The use of computer-based systems allows for a great variety of possible configurations, combinations, and divisions of tasks and functionality between and among components. Computer-implemented operations can be performed on a single component or across multiple components. Computer-implements tasks and/or operations can be performed sequentially or in parallel. Data and instructions can be stored in a single memory device or across multiple memory devices.

Aspects of the disclosure have been described in terms of illustrative embodiments thereof. Numerous other embodiments, modifications, and/or variations within the scope and spirit of the appended claims can occur to persons of ordinary skill in the art from a review of this disclosure. Any and all features in the following claims can be combined and/or rearranged in any way possible. Accordingly, the scope of the present disclosure is by way of example rather than by way of limitation, and the subject disclosure does not preclude inclusion of such modifications, variations or additions to the present subject matter as would be readily apparent to one of ordinary skill in the art. Moreover, terms are described herein using lists of example elements joined by conjunctions such as “and,” “or,” “but,” etc. It should be understood that such conjunctions are provided for explanatory purposes only. Lists joined by a particular conjunction such as “or,” for example, can refer to “at least one of” or “any combination of” example elements listed therein. Also, terms such as “based on” should be understood as “based at least in part on”.

Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the claims discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure. Some of the claims are described with a letter reference to a claim element for exemplary illustrated purposes and is not meant to be limiting. The letter references do not imply a particular order of operations. For instance, letter identifiers such as (a), (b), (c), . . . , (i), (ii), (iii), . . . , etc. may be used to illustrate method operations. Such identifiers are provided for the ease of the reader and do not denote a particular order of steps or operations. An operation illustrated by a list identifier of (a), (i), etc. can be performed before, after, and/or in parallel with another operation illustrated by a list identifier of (b), (ii), etc.