MAINTENANCE OF AUTONOMOUS VEHICLE TESTS

The disclosed technology provides solutions for maintaining autonomous vehicle (AV) tests and, provides methods for evaluating test relevance and for determining how to fix outdated AV tests. In some aspects, a process of the disclosed technology includes steps for associating a set of test metrics with an AV test, monitoring operation of an AV to identify one or more behaviors performed by the AV in the simulated environment and determining a validity of the AV test with respect to the simulated environment based on the AV behaviors and the set of test metrics. Systems and machine-readable media are also provided.

BACKGROUND

1. Technical Field

The disclosed technology provides solutions for maintaining autonomous vehicle (AV) tests and in particular, provides methods for evaluating test relevance and for determining how to fix outdated tests.

Autonomous vehicles (AVs) are vehicles having computers and control systems that perform driving and navigation tasks conventionally performed by human drivers. As AV technologies continue to advance, are increasingly used to improve transportation efficiency and safety. As such, AVs need to perform many of the functions typically performed by human drivers. Such tasks may require the collection and processing of large quantities of data using various sensor types, including but not limited to cameras, Radio Detection and Ranging (RADAR) sensors, and/or Light Detection and Ranging (LiDAR) sensors disposed on the AV. In some instances, the collected data can be used by the AV to perform tasks relating to routing, planning, and obstacle avoidance. To ensure safe and efficient operation these various AV systems require extensive testing and training.

DETAILED DESCRIPTION

To ensure adequate safety and performance, autonomous vehicles (AVs) must undergo extensive testing before they can be deployed in real-world settings. In some instances, AV performance can be evaluated using AV tests designed to determine if the AV can adequately perform under certain conditions, such as by safely and efficiently navigating different driving scenarios. As used herein, AV tests can include a set of programmatic routines or applications that are designed to verify and/or evaluate the performance of specific AV behaviors and/or characteristics, for example, when AV operations are performed in a simulated test environment. As such, AV tests can be used to validate the successful completion of any number of a variety of AV behaviors or maneuvers (e.g., the completion of a full stop, a successful unprotected left-turn maneuver, etc.) under various conditions. Additionally, AV tests may be used to check on the occurrence (or non-occurrence) of specific events during a given test scenario. By way of example, AV tests may be configured to check for the occurrence of a collision with other entities (e.g., vehicles and/or pedestrians), or entry into non-drivable areas (e.g., driving up on curb sides) in the simulated environment. Additionally, in some implementations, tests can be used to verify where and/or when an AV is exhibiting ‘asserting’ behavior, as opposed to ‘stopped’ behavior, e.g., to determine where the AV is actively engaging traffic situations and successfully navigating scene conditions, and where the AV is stopped or is in a holding pattern of non-engagement. In some implementations, AV tests may also be used to identify when or where emergency stops (or safe stops) are triggered, for example, to identify instances where the AV has encountered a scenario that it may have difficulty navigating or where the AV has encountered a dangerous situation.

One limitation in the use of AV tests is that tests can become less effective (or obsolete) over time, for example, due to changes in AV software (e.g., changes/updates to the AV stack), and/or due to changes in the (simulated) environment in which the tests are applied/run. Additionally, as the number of available tests increases, it becomes progressively difficult for technicians to determine what tests remain valid and which have become obsolete, as well as to identify which invalid tests may be fixed with minimal updates.

Aspects of the disclosed technology provide solutions for evaluating AV test relevance and for identifying outdated (or atrophied) AV tests. Additionally, the disclosed technology provides solutions for identifying outdated/atrophied AV tests that may be easily repaired or updated, for example, by modifying an evaluation window associated with the test that identifies a specific time-period (e.g., a start-time and end-time) of AV operation for which the test can be applied.

In some approaches, AV test maintenance can be facilitated using pre-defined test intent metrics (also referred to as: test metrics or intent metrics) that can be used to determine or quantify how closely an AV followed a desired intent path when navigating a provided test scenario. Test metrics can define one or more target AV behaviors to be evaluated by a given AV test. As used herein, AV behaviors can be (or may include) various vehicle maneuvers (e.g., turns, lane changes, velocity changes, etc.) and/or changes to the AV trajectory/route, etc. Test metrics can be associated with a given AV test, along with a predefined intent path, for example, that specifies a time-series of AV positions (e.g., an AV trajectory) and/or behaviors to be evaluated by a given test. As such, test metrics can be used to provide a means to evaluate a degree to which an AV performance in each test scenario adhered to the intent path. A set of test metrics can depend on (and correspond with) the associated intent path of the AV. For example, the intent path may identify a time-series of AV behaviors or maneuvers that are to occur at different times (or locations) along an AV's trajectory through a driving scene. By way of example, the intent path may specify an ordering of AV behaviors (e.g., stop, turn left, and then park-at-destination, etc.), as well as times and/or regions/zones within the driving scene where each behavior/maneuver is to be performed.

Test intent metrics can consist of or otherwise include a predefined set of criteria—for each AV behavior/maneuver along the intent path—that can provide quantitative measures of (1) whether the AV successfully completed the intended behavior or maneuver, and (2) how well the maneuver or behavior was executed. By way of example, test metrics can include metrics relating to vehicle kinematics, such as velocity, acceleration (e.g., longitudinal and/or lateral acceleration), lane identifiers indicating locations of the AV on specific road segments, and the like.

FIG.1illustrates a block diagram of an example system100for validating autonomous vehicle (AV) tests using various AV test metrics. As illustrated in the example ofFIG.1, AV test generation102can be performed in a manner such that the test is designed to provide a set of criteria (e.g., AV behaviors and/or maneuvers) to be tested with respect to the AV. By way of example, an AV test may include programmatic code or other instructions that are configured to monitor outputs at various layers of an AV stack during a simulated operation of the AV, e.g., in a simulated environment or virtual driving scenario. The test may include checks to determine the occurrence (or non-occurrence) of specific events, such as collisions, dangerous maneuvers by the AV (e.g., driving into non-drivable areas), and/or the performance of other specific maneuvers or behaviors, e.g., stops, turns, lane changes, speed changes, and/or acceleration changes, etc.

For each test, a set of specific (and possibly unique) test metrics can be designated (block104). The test metrics can provide a way to evaluate AV performance with respect to a given test, i.e., how well (or how closely) the AV adhered to an intent path. Depending on the desired implementation, test metrics may provide or indicate quantitative measures for adherence to a specific intent characteristic. By way of example, if a given intent path indicates a stop at a particular location, the intent metric may include a binary indicator (e.g., a yes/no or zero/one that the stop was performed). By way of further example, if the intent path specifies a range of vehicle speeds or headings, then the intent metric may be similarly represented, e.g., as a range of speeds or vehicle headings. In other instances, intent metrics may be represented as a probability, e.g., on an interval of [0, 1], where 0 represents a low (or 0%) probability of event occurrence, and a 1 represents a high certainty (100%) of event occurrence. Event probabilities can be used to quantify probabilities or likelihoods of certain events, such as that the AV will collide with another entity along its trajectory, and/or than an entity will move into a path of the AV, etc. The test metrics and the intent path can be associated with the AV test (block110), for example, so that each test can be associated with a set of criteria that can be used to determine the validity of the associated test.

At block112, modifications can be made to the AV software, such as changes/upgrades to the AV stack. Additionally, block112can include changes to a synthetic scene in which AV performance may be evaluated. Such changes can cause the originally generated test (block102) to become outdated or obsolete for the intended purpose; as such, the intent metrics can be used to determine how well an AV (e.g., AV106) is able to adhere to a defined intent path. By way of example, driving data108collected from AV106can be used to run an AV test (block114). In some instances, the AV test may be run in a replay scenario where operation of AV106is simulated against an environment recorded by the AV sensors and that is represented in driving data108. As such, driving data108can include recorded sensor data for various locations or scenarios previously encountered by the AV106. However, updates or other changes to software of the AV106can be tested using the AV test at block114. Subsequently, a performance of the AV106in the test scenario can be validated at block116.

In another example, an AV test may be run (block114) to test a new driving scenario, for example, that is different from that represented by driving data108. In such instances, the performance of AV106in the new (synthetic or virtual) driving scenario can also be validated using the test metrics (from block104) to validate how well the AV106was able to adhere to an intent path associated with the AV test. In some approaches, test metrics may be used to indicate how closely a path or trajectory of AV106in the synthetic driving scenario matches a path/trajectory of the AV106represented in driving data108. By way of example, a root mean square (RMS) calculation may be used to determine Euclidean distances between locations and/or poses of AV106represented by driving data108against those identified in the synthetic driving scenario.

FIG.2illustrates a simplified block diagram of an example system200for fixing or updating one or more outdated AV tests. System200includes a test repository202that is configured to store a multitude of AV tests, e.g., that have been created for the purpose of testing various AV systems and/or behaviors, as discussed above with respect to block102inFIG.1. The test repository can be used to identify/segment tests using their associated test metrics (block204). In some approaches, AV operation can be simulated in a (synthetic) environment and test metrics can be collected with respect to the administered test. That is, the test metrics can be used at block204to identify which tests in test repository202may be outdated (or atrophied) and may need to be updated. By way of example, segmentation of tests from test repository202can be based on a predetermined test metric threshold, below which, the test may be identified as ‘out-of-date’ or in need of revision.

The AV tests identified and segmented at block204may be analyzed to determine if they can be easily revised/updated, e.g., to be brought up-to-date based on changes to the AV software and/or synthetic scenario in which the test is conducted. In some approaches, a machine-learning model206may be used to determine/identify which of the segmented tests may be updated. For example, the machine-learning model206may be trained to identify AV tests that may be brought up to date by modifying one or more specific parameters, such as an evaluation window in which the test is applied. By way of example, machine-learning model206may be configured to process those tests from repository202that have test metrics below a predetermined threshold (e.g., indicating that they are out of date), and, for each test, determine a probability that the test can be brought up-to-date through modification of an associated evaluation window. By way of example, the evaluation window can identify a specific time-period (e.g., a start-time and end-time) of AV operation for which the test can be applied.

FIG.3illustrates a flow diagram of an example process300for validating AV tests using associated test metrics. At step302, the process300includes associating a set of test metrics with an autonomous vehicle (AV) test. Test metrics can be used to evaluate or quantify a performance of the AV with respect to an intent-path for an applied AV test. As discussed above, the intent path can specify a trajectory (or time-series) of AV positions/locations and/or behaviors with respect to a given AV test.

At step304, the process300includes monitoring operation of an AV to identify one or more behaviors performed by the AV in the simulated environment. As discussed above, the test metrics can be used to evaluate the AV's adherence to a predefined intent path, such as the completion of one or more intended events, behaviors and/or tasks along the intent path. By way of example, the intent path may specify a particular route or trajectory of the AV, along which, the AV is intended to perform specific maneuvers, such as turns and/or lane changes etc. In this example, a lower test-metric scoring may indicate a low adherence to the defined intent path, e.g., that the AV was unable to adhere to the intended trajectory and/or unable to complete one or more of the defined behaviors (maneuvers) specified by the test. Conversely, a higher test metric scoring may indicate a high adherence to the defined intent path, e.g., that the AV correctly navigated the intended trajectory/path and completed the requisite behaviors/maneuvers defined by the path.

At step306, process300includes determining a validity of the AV test based on the set of test metrics. The validity of the AV test may be determined based on the test metrics resulting from simulation of the AV using a given AV test (e.g., step304, discussed above). By way of example, a particular AV test may be determined to be out-of-date or obsolete if the metrics resulting from application of the test are not reproducible, if they indicate a failure to meet the test intent, or if they indicate erroneous results.

By way of example, if an AV test is designed to check a path or trajectory of an AV through a given driving scenario, but test metrics for repeated applications of the test do not correspond (e.g., the test metrics are different between test instances), then the AV test may be determined to be invalid, i.e., faulty or obsolete. In another example, if an AV test is designed to verify certain maneuvers (e.g., turns or stops) performed by the AV and the test metrics indicate that the AV was stopped or stuck in a single location, then it may be determined, based on the test metrics, that the test is invalid, e.g., for failing to achieve the test intent.

FIG.4illustrates a flow diagram of an example process400for updating AV tests. At step402, the process400includes segmenting two or more AV tests based on associated test metrics. As discussed above with respect toFIG.2, test metrics can be evaluated for several tests, using various AV software versions and/or synthetic test scenarios. Based on the test metrics for each test, a determination can be made as to whether a given test is up-to-date, or if it is out-of-date and needs to be revised. By way of example, AV tests with test metric scores below a predetermined threshold may be segmented or selected for potential revision or update, whereas tests having metrics above the threshold may be left unaltered.

At step404, the process400includes identifying one or more of the segmented tests that can be fixed/updated by modifying an associated evaluation window. As such, the test database can be first segmented according to test metrics associated with each test (step402), and then further segmented based on an identification of which of (pre-segmented) tests may be updated by modifying an associated evaluation window. By way of example, some of the segmented tests (which may be identified as obsolete or out of date) may be fixable by altering the evaluation window in which the test is applied, for example, by changing either the start time or end time of the test application with respect to the AV simulation.

In some aspects, identification of tests that can be fixed/updated may be performed using a machine-learning model. As discussed above with respect toFIG.3, a machine-learning model that has been trained to identify fixable/upgradeable tests can be used to assist with test segmentation. In some instances, tests may be updated, for example, by modifying an evaluation window associated with the test, e.g., to change the time period in which the test is applied to the AV simulation.

In instances where one or more machine-learning models are used to determine the feasibility of test repair or update, the machine-learning models may be trained using sets of training data that include a multitude of tests and their associated test metrics. That is, the machine-learning model may be trained based on test/test metric pairs, e.g., to identify (or classify) test instances that can be repaired through modification of evaluation window parameters. Further details regarding the implementation of machine learning models are provided with respect toFIG.5, discussed below.

FIG.5is an illustrative example of a deep learning neural network500that can be implemented to facilitate a process for updating one or more AV tests. In one illustrative example, the input layer520can be configured to receive test data and/or associated test metric data associated with a given AV test, and at output layer521output an indication as to whether the inputted test can be updated by modifying an evaluation window. In some examples, the output layer521may be configured to output a new evaluation window (e.g., a start time and an end time) that could be used to fix or update a corresponding test. The neural network500includes multiple hidden layers522a,522b, through522n. The hidden layers522a,522b, through522ninclude “n” number of hidden layers, where “n” is an integer greater than or equal to one. The number of hidden layers can be made to include as many layers as needed for the given application. The neural network500further includes an output layer521that provides an output resulting from the processing performed by the hidden layers522a,522b, through522n.

Information can be exchanged between nodes through node-to-node interconnections between the various layers. Nodes of the input layer520can activate a set of nodes in the first hidden layer522a. For example, as shown, each of the input nodes of the input layer520is connected to each of the nodes of the first hidden layer522a. The nodes of the first hidden layer522acan transform the information of each input node by applying activation functions to the input node information. The information derived from the transformation can then be passed to and can activate the nodes of the next hidden layer522b, which can perform their own designated functions. Example functions include convolutional, up-sampling, data transformation, and/or any other suitable functions. The output of the hidden layer522bcan then activate nodes of the next hidden layer, and so on. The output of the last hidden layer522ncan activate one or more nodes of the output layer521, at which an output is provided. In some cases, while nodes (e.g., node526) in the neural network500are shown as having multiple output lines, a node can have a single output and all lines shown as being output from a node represent the same output value.

In some cases, each node or interconnection between nodes can have a weight that is a set of parameters derived from the training of the neural network500. Once the neural network500is trained, it can be referred to as a trained neural network, which can be used to classify one or more activities. For example, an interconnection between nodes can represent a piece of information learned about the interconnected nodes. The interconnection can have a tunable numeric weight that can be tuned (e.g., based on a training dataset), allowing the neural network500to be adaptive to inputs and able to learn as more and more data is processed.

The neural network500is pre-trained to process the features from the data in the input layer520using the different hidden layers522a,522b, through522nin order to provide the output through the output layer521. In some cases, the neural network500can adjust the weights of the nodes using a training process called backpropagation. As noted above, a backpropagation process can include a forward pass, a loss function, a backward pass, and a weight update. The forward pass, loss function, backward pass, and parameter update is performed for one training iteration. The process can be repeated for a certain number of iterations for each set of training data until the neural network500is trained well enough so that the weights of the layers are accurately tuned.

A loss function can be used to analyze error in the output. Any suitable loss function definition can be used, such as a Cross-Entropy loss. Another example of a loss function includes the mean squared error (MSE), defined as E_total=Σ=(½(target−output)2). The loss can be set to be equal to the value of E_total. The goal of training is to minimize the amount of loss so that the predicted output is the same as the training label. The neural network500can perform a backward pass by determining which inputs (weights) most contributed to the loss of the network and can adjust the weights so that the loss decreases and is eventually minimized. A derivative of the loss with respect to the weights (denoted as dL/dW, where W are the weights at a particular layer) can be computed to determine the weights that contributed most to the loss of the network. After the derivative is computed, a weight update can be performed by updating all the weights of the filters. For example, the weights can be updated so that they change in the opposite direction of the gradient. The weight update can be denoted as w=w_i−η dL/dW, where w denotes a weight, wi denotes the initial weight, and η denotes a learning rate. The learning rate can be set to any suitable value, with a high learning rate including larger weight updates and a lower value indicating smaller weight updates.

As understood by those of skill in the art, machine-learning based classification techniques can vary depending on the desired implementation. For example, machine-learning classification schemes can utilize one or more of the following, alone or in combination: hidden Markov models; recurrent neural networks; convolutional neural networks (CNNs); deep learning; Bayesian symbolic methods; general adversarial networks (GANs); support vector machines; image registration methods; applicable rule-based system. Where regression algorithms are used, they may include including but are not limited to: a Stochastic Gradient Descent Regressor, and/or a Passive Aggressive Regressor, etc.

In this example, the AV management system600includes an AV602, a data center150, and a client computing device170. The AV602, the data center650, and the client computing device670can communicate with one another over one or more networks (not shown), such as a public network (e.g., the Internet, an Infrastructure as a Service (IaaS) network, a Platform as a Service (PaaS) network, a Software as a Service (SaaS) network, other Cloud Service Provider (CSP) network, etc.), a private network (e.g., a Local Area Network (LAN), a private cloud, a Virtual Private Network (VPN), etc.), and/or a hybrid network (e.g., a multi-cloud or hybrid cloud network, etc.).

AV602can navigate roadways without a human driver based on sensor signals generated by multiple sensor systems604,606, and608. The sensor systems604-608can include different types of sensors and can be arranged about the AV602. For instance, the sensor systems604-608can comprise Inertial Measurement Units (IMUs), cameras (e.g., still image cameras, video cameras, etc.), optical sensors (e.g., LIDAR systems, ambient light sensors, infrared sensors, etc.), RADAR systems, GPS receivers, audio sensors (e.g., microphones, Sound Navigation and Ranging (SONAR) systems, ultrasonic sensors, etc.), engine sensors, speedometers, tachometers, odometers, altimeters, tilt sensors, impact sensors, airbag sensors, seat occupancy sensors, open/closed door sensors, tire pressure sensors, rain sensors, and so forth. For example, the sensor system604can be a camera system, the sensor system606can be a LIDAR system, and the sensor system608can be a RADAR system. Other embodiments may include any other number and type of sensors.

The AV602can also include several mechanical systems that can be used to maneuver or operate the AV602. For instance, the mechanical systems can include a vehicle propulsion system630, a braking system632, a steering system634, a safety system636, and a cabin system638, among other systems. The vehicle propulsion system630can include an electric motor, an internal combustion engine, or both. The braking system632can include an engine brake, brake pads, actuators, and/or any other suitable componentry configured to assist in decelerating the AV602. The steering system634can include suitable componentry configured to control the direction of movement of the AV602during navigation. The safety system636can include lights and signal indicators, a parking brake, airbags, and so forth. The cabin system638can include cabin temperature control systems, in-cabin entertainment systems, and so forth. In some embodiments, the AV602might not include human driver actuators (e.g., steering wheel, handbrake, foot brake pedal, foot accelerator pedal, turn signal lever, window wipers, etc.) for controlling the AV602. Instead, the cabin system638can include one or more client interfaces (e.g., Graphical User Interfaces (GUIs), Voice User Interfaces (VUIs), etc.) for controlling certain aspects of the mechanical systems630-638.

The AV602can additionally include a local computing device610that is in communication with the sensor systems604-608, the mechanical systems630-638, the data center650, and the client computing device670, among other systems. The local computing device610can include one or more processors and memory, including instructions that can be executed by the one or more processors. The instructions can make up one or more software stacks or components responsible for controlling the AV602; communicating with the data center650, the client computing device670, and other systems; receiving inputs from riders, passengers, and other entities within the AV's environment; logging metrics collected by the sensor systems604-608; and so forth. In this example, the local computing device610includes a perception stack612, a mapping and localization stack614, a prediction stack616, a planning stack618, a communications stack620, a control stack622, an AV operational database624, and an HD geospatial database626, among other stacks and systems.

The perception stack612can enable the AV602to “see” (e.g., via cameras, LIDAR sensors, infrared sensors, etc.), “hear” (e.g., via microphones, ultrasonic sensors, RADAR, etc.), and “feel” (e.g., pressure sensors, force sensors, impact sensors, etc.) its environment using information from the sensor systems604-608, the mapping and localization stack614, the HD geospatial database626, other components of the AV, and other data sources (e.g., the data center650, the client computing device670, third party data sources, etc.). The perception stack612can detect and classify objects and determine their current locations, speeds, directions, and the like. In addition, the perception stack612can determine the free space around the AV602(e.g., to maintain a safe distance from other objects, change lanes, park the AV, etc.). The perception stack612can also identify environmental uncertainties, such as where to look for moving objects, flag areas that may be obscured or blocked from view, and so forth. In some embodiments, an output of the prediction stack can be a bounding area around a perceived object that can be associated with a semantic label that identifies the type of object that is within the bounding area, the kinematic of the object (information about its movement), a tracked path of the object, and a description of the pose of the object (its orientation or heading, etc.).

Mapping and localization stack614can determine the AV's position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database626, etc.). For example, in some embodiments, the AV602can compare sensor data captured in real-time by the sensor systems604-608to data in the HD geospatial database626to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV602can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV602can use mapping and localization information from a redundant system and/or from remote data sources.

The prediction stack616can receive information from the localization stack614and objects identified by the perception stack612and predict a future path for the objects. In some embodiments, the prediction stack616can output several likely paths that an object is predicted to take along with a probability associated with each path. For each predicted path, the prediction stack616can also output a range of points along the path corresponding to a predicted location of the object along the path at future time intervals along with an expected error value for each of the points that indicates a probabilistic deviation from that point.

The planning stack618can determine how to maneuver or operate the AV602safely and efficiently in its environment. For example, the planning stack618can receive the location, speed, and direction of the AV602, geospatial data, data regarding objects sharing the road with the AV602(e.g., pedestrians, bicycles, vehicles, ambulances, buses, cable cars, trains, traffic lights, lanes, road markings, etc.) or certain events occurring during a trip (e.g., emergency vehicle blaring a siren, intersections, occluded areas, street closures for construction or street repairs, double-parked cars, etc.), traffic rules and other safety standards or practices for the road, user input, and other relevant data for directing the AV602from one point to another and outputs from the perception stack612, localization stack614, and prediction stack616. The planning stack618can determine multiple sets of one or more mechanical operations that the AV602can perform (e.g., go straight at a specified rate of acceleration, including maintaining the same speed or decelerating; turn on the left blinker, decelerate if the AV is above a threshold range for turning, and turn left; turn on the right blinker, accelerate if the AV is stopped or below the threshold range for turning, and turn right; decelerate until completely stopped and reverse; etc.), and select the best one to meet changing road conditions and events. If something unexpected happens, the planning stack618can select from multiple backup plans to carry out. For example, while preparing to change lanes to turn right at an intersection, another vehicle may aggressively cut into the destination lane, making the lane change unsafe. The planning stack618could have already determined an alternative plan for such an event. Upon its occurrence, it could help direct the AV602to go around the block instead of blocking a current lane while waiting for an opening to change lanes.

The control stack622can manage the operation of the vehicle propulsion system630, the braking system632, the steering system634, the safety system636, and the cabin system638. The control stack622can receive sensor signals from the sensor systems604-608as well as communicate with other stacks or components of the local computing device610or a remote system (e.g., the data center650) to effectuate operation of the AV602. For example, the control stack622can implement the final path or actions from the multiple paths or actions provided by the planning stack618. This can involve turning the routes and decisions from the planning stack618into commands for the actuators that control the AV's steering, throttle, brake, and drive unit.

The communications stack620can transmit and receive signals between the various stacks and other components of the AV602and between the AV602, the data center650, the client computing device670, and other remote systems. The communications stack620can enable the local computing device610to exchange information remotely over a network, such as through an antenna array or interface that can provide a metropolitan WIFI network connection, a mobile or cellular network connection (e.g., Third Generation (3G), Fourth Generation (4G), Long-Term Evolution (LTE), 5th Generation (5G), etc.), and/or other wireless network connection (e.g., License Assisted Access (LAA), Citizens Broadband Radio Service (CBRS), MULTEFIRE, etc.). The communications stack620can also facilitate the local exchange of information, such as through a wired connection (e.g., a user's mobile computing device docked in an in-car docking station or connected via Universal Serial Bus (USB), etc.) or a local wireless connection (e.g., Wireless Local Area Network (WLAN), Bluetooth®, infrared, etc.).

The AV operational database624can store raw AV data generated by the sensor systems604-608, stacks612-622, and other components of the AV602and/or data received by the AV602from remote systems (e.g., the data center650, the client computing device670, etc.). In some embodiments, the raw AV data can include HD LIDAR point cloud data, image data, RADAR data, GPS data, and other sensor data that the data center650can use for creating or updating AV geospatial data or for creating simulations of situations encountered by AV602for future testing or training of various machine learning algorithms that are incorporated in the local computing device610.

The data center650can be a private cloud (e.g., an enterprise network, a co-location provider network, etc.), a public cloud (e.g., an Infrastructure as a Service (IaaS) network, a Platform as a Service (PaaS) network, a Software as a Service (SaaS) network, or other Cloud Service Provider (CSP) network), a hybrid cloud, a multi-cloud, and so forth. The data center650can include one or more computing devices remote to the local computing device610for managing a fleet of AVs and AV-related services. For example, in addition to managing the AV602, the data center650may also support a ridesharing service, a delivery service, a remote/roadside assistance service, street services (e.g., street mapping, street patrol, street cleaning, street metering, parking reservation, etc.), and the like.

The data center650can send and receive various signals to and from the AV602and the client computing device670. These signals can include sensor data captured by the sensor systems604-608, roadside assistance requests, software updates, ridesharing pick-up and drop-off instructions, and so forth. In this example, the data center650includes a data management platform652, an Artificial Intelligence/Machine Learning (AI/ML) platform654, a simulation platform656, a remote assistance platform658, and a ridesharing platform660, and a map management platform662, among other systems.

The AI/ML platform654can provide the infrastructure for training and evaluating machine learning algorithms for operating the AV602, the simulation platform656, the remote assistance platform658, the ridesharing platform660, the map management platform662, and other platforms and systems. Using the AI/ML platform654, data scientists can prepare data sets from the data management platform652; select, design, and train machine learning models; evaluate, refine, and deploy the models; maintain, monitor, and retrain the models; and so on.

The simulation platform656can enable testing and validation of the algorithms, machine learning models, neural networks, and other development efforts for the AV602, the remote assistance platform658, the ridesharing platform660, the map management platform662, and other platforms and systems. The simulation platform656can replicate a variety of driving environments and/or reproduce real-world scenarios from data captured by the AV602, including rendering geospatial information and road infrastructure (e.g., streets, lanes, crosswalks, traffic lights, stop signs, etc.) obtained from a cartography platform (e.g., map management platform662); modeling the behavior of other vehicles, bicycles, pedestrians, and other dynamic elements; simulating inclement weather conditions, different traffic scenarios; and so on.

The remote assistance platform658can generate and transmit instructions regarding the operation of the AV602. For example, in response to an output of the AI/ML platform654or other system of the data center650, the remote assistance platform658can prepare instructions for one or more stacks or other components of the AV602.

The ridesharing platform660can interact with a customer of a ridesharing service via a ridesharing application672executing on the client computing device670. The client computing device670can be any type of computing system, including a server, desktop computer, laptop, tablet, smartphone, smart wearable device (e.g., smartwatch, smart eyeglasses or other Head-Mounted Display (HMD), smart ear pods, or other smart in-ear, on-ear, or over-ear device, etc.), gaming system, or other general purpose computing device for accessing the ridesharing application672. The client computing device670can be a customer's mobile computing device or a computing device integrated with the AV602(e.g., the local computing device610). The ridesharing platform660can receive requests to pick up or drop off from the ridesharing application672and dispatch the AV602for the trip.

In some embodiments, the map viewing services of map management platform662can be modularized and deployed as part of one or more of the platforms and systems of the data center650. For example, the AI/ML platform654may incorporate the map viewing services for visualizing the effectiveness of various object detection or object classification models, the simulation platform656may incorporate the map viewing services for recreating and visualizing certain driving scenarios, the remote assistance platform658may incorporate the map viewing services for replaying traffic incidents to facilitate and coordinate aid, the ridesharing platform660may incorporate the map viewing services into the client application672to enable passengers to view the AV602in transit en route to a pick-up or drop-off location, and so on.

FIG.7illustrates an example apparatus (e.g., a processor-based system) with which some aspects of the subject technology can be implemented. For example, processor-based system700can be any computing device making up internal computing system710, remote computing system750, a passenger device executing the rideshare app770, internal computing device730, or any component thereof in which the components of the system are in communication with each other using connection705. Connection705can be a physical connection via a bus, or a direct connection into processor710, such as in a chipset architecture. Connection705can also be a virtual connection, networked connection, or logical connection.

Example system700includes at least one processing unit (CPU or processor)710and connection705that couples various system components including system memory715, such as read-only memory (ROM)720and random-access memory (RAM)725to processor710. Computing system700can include a cache of high-speed memory712connected directly with, in close proximity to, or integrated as part of processor710.

Processor710can include any general-purpose processor and a hardware service or software service, such as services732,734, and736stored in storage device730, configured to control processor710as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor710may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

Storage device730can include software services, servers, services, etc., that when the code that defines such software is executed by the processor710, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor710, connection705, output device735, etc., to carry out the function.