Estimating depth information for stereoscopic images for robotic systems and applications

Abstract

The invention discloses estimating depth information for stereoscopic images for robotic systems and applications. In various examples, techniques for estimating depth information of a stereoscopic image with reduced estimation inaccuracy by performing a depth accuracy evaluation. The technique includes generating a depth map associated with a first image of a stereoscopic image pair based at least on stereoscopic features of the first image. The technique further includes generating a confidence map representing a probability that depth values in the generated depth map are accurate based at least on the stereoscopic features of the first image. The technique further includes updating one or more portions of the generated depth map based at least on the confidence map.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 637,119, filed April 22, 2024, which is hereby incorporated by reference in its entirety. BACKGROUND

[0003] A computer vision system with stereovision capability (referred to herein as a computer stereovision system) typically perceives objects in a real-world scene based on a pair of two-dimensional (2D) digital images of the scene captured using two cameras (e.g., stereo cameras) with a mutual horizontal displacement. Such a pair of 2D digital images is often referred to as a stereo image pair, left-right stereo images, or simply left-right images. The system perceives the scene in three-dimensions (3D) by extracting depth information from the stereo image pair. Depth information is typically computed based on the distance between two corresponding image points in the stereo image pair (often referred to as the disparity between the two points). Such systems can be used in autonomous mobile robots (AMRs), autonomous or semi-autonomous machines (e.g., vehicles, watercraft, drones, etc.), or otherwise as part of a perception system configured to perceive the depth of objects and structures in its surrounding environment in real-time or near real-time. Such systems can also be used in robotic arms or other manipulators as part of a perception system configured to perceive the depth of itself and objects it manipulates in real-time or near real-time.

[0004] A computer stereovision system can predict a depth map for a left stereo image or a right stereo image. For example, a depth map for a left stereo image shows a depth value for each pixel of the stereo image. Such a depth map is typically represented as a 2D array / vector of depth values. The depth map is typically computed based on a disparity map that has been predicted for the same stereo image and the intrinsic of the stereo cameras. The terms depth map and disparity map are used interchangeably hereinafter.

[0005] In some existing approaches, such a computer stereo vision system is implemented as a machine learning model trained using a regression loss. Due to the continuous nature of the regression loss, the depth map computed by the system often includes one or more regions of inaccurate depth values. Specifically, the depth values computed for objects in the foreground of the input stereo images often gradually shift towards the depth values computed for the background and then overlap with the depth values computed for the background. This system behavior is often referred to as “depth bleeding,” which can cause problems for downstream applications or systems. For example, when a point cloud is constructed using a depth map with a depth bleeding problem, the objects constructed from the point cloud can have edges that are interconnected with the background. Such interconnected edges can cause a navigation system (e.g., in an AMR) to perceive an obstacle in the real-world scene that does not actually exist, and thus decide not to navigate through that region of the interconnected edges.

[0006] Some solutions to depth bleeding are implemented in the architecture of a given machine learning model (e.g., the architecture of the neural networks that make up the model structure). However, because these solutions often make assumptions that are only valid in narrow and simple cases, they are not effective in removing depth bleeding in other cases (e.g., complex application environments). For example, stereo mixed density networks (SMD-nets) are one such solution that assumes the distribution of the generated depth information is close to a bimodal distribution (e.g., foreground and background), and is configured to output one of the two assumed bimodal peak depth values as a way to remove depth bleeding. Thus, SMD-nets are not effective in removing depth bleeding when the generated depth information constitutes a more complex distribution (e.g., a polynomial distribution). Furthermore, these solutions are often implemented as large models that require a large amount of runtime memory and computation, thus making them generally unsuitable for real-time or near real-time applications or systems, such as the computer stereo vision system described above.

[0007] Accordingly, there is a need for more effective techniques for computer stereo vision systems to address the problem of depth bleeding. SUMMARY

[0008] Embodiments of the present disclosure are directed to estimating depth information for a stereo image with reduced estimated inaccuracy by performing a depth accuracy evaluation. The techniques described herein include generating a depth map associated with a first image of a stereo image pair based at least on stereo features of the first image. The techniques also include generating a confidence map representing a probability that a depth value in the generated depth map is accurate based at least on the stereo features of the first image. The techniques further include updating one or more portions of the generated depth map based at least on the confidence map.

[0009] The disclosed technology provides several technical advantages over previous approaches. In particular, since the disclosed technology removes depth values generated by the depth estimation model having a low confidence score, the inaccuracy of the depth values is reduced. Moreover, since the disclosed technology trains the depth estimation model to estimate depth information for a stereo image and evaluate the accuracy of the estimated depth information in the same inference process (rather than two separate processes), computational efficiency is improved, providing an implementation that enables real-time or near real-time deployment. BRIEF DESCRIPTION OF DRAWINGS

[0010] The present systems and methods for estimating depth information for a stereo image with reduced estimated inaccuracy by performing depth accuracy evaluation are described in detail below with reference to the accompanying drawings, in which:

[0011] Figure 1 A system configured to implement one or more aspects of the various embodiments is shown;

[0012] Figure 2 is an illustration of an example inference process using a depth estimation model in accordance with the various embodiments;

[0013] Figure 3 An example process for training a depth estimation model in accordance with the various embodiments is shown;

[0014] Figures 4A-4B An example process for training a depth estimation model in accordance with the various embodiments is shown;

[0015] Figure 5 A flowchart of a method in accordance with the various embodiments is shown;

[0016] Figure 6A is an illustration of an example autonomous vehicle in accordance with some embodiments of the present disclosure;

[0017] Figure 6B is an illustration of an example autonomous vehicle in accordance with some embodiments of the present disclosure; Figure 6A example camera positions and fields of view of the example autonomous vehicle of

[0018] Figure 6C is an illustration of an example autonomous vehicle in accordance with some embodiments of the present disclosure; Figure 6A block diagram of an example system architecture of the example autonomous vehicle of

[0019] Figure 6D is a system diagram of communication between a cloud-based server and the example autonomous vehicle of Figure 6A

[0020] Figure 7A is a block diagram of an example generative language model system suitable for implementing at least some embodiments of the present disclosure;

[0021] ​Figure 7B is a block diagram of an example generative language model including a transformer encoder-decoder suitable for implementing at least some embodiments of the present disclosure;

[0022] Figure 7C is a block diagram of an example generative language model including a decoder-only transformer architecture suitable for implementing at least some embodiments of the present disclosure;

[0023] Figure 8 is a block diagram of an example computing device suitable for implementing at least some embodiments of the present disclosure;

[0024] Figure 9 is a block diagram of an example data center suitable for implementing at least some embodiments of the present disclosure. DETAILED DESCRIPTION

[0025] Techniques are disclosed for computing depth maps of stereo image pairs (e.g., two or more images captured using two or more image sensors having at least partially overlapping fields of view) using a depth estimation model, and reducing inaccuracies (and thus depth leakage) in the computed depth maps based on evaluating the accuracy of the depth maps. In at least one embodiment, to compute a depth map for a given stereo image (e.g., a left stereo image), the depth estimation model extracts a set of feature maps from each stereo image. Each feature map in the set of feature maps represents a different feature, and is commonly referred to as a feature channel or channel. These channels are collectively referred to as channel dimensions. Given two sets of feature maps, a feature correlation engine computes feature correlations between the two sets of feature maps.

[0026] Given the computed feature correlations and the set of feature maps for the left stereo image (also referred to as the left feature map set), a depth estimation engine first generates stereo features for the left stereo image, and then generates a depth map for the left stereo image based on the generated stereo features. Given the generated stereo features, a depth accuracy evaluation engine computes a confidence map with confidence scores that represent probabilities that depth values in the generated depth map are accurate. A post-process removes depth values with low confidence scores from the depth map based on the confidence map, before the depth map is provided to downstream processing. In this way, the depth estimation model can effectively reduce depth inaccuracies (and thus reduce the depth leakage problem) in the generated depth map.

[0027] At least two methods (but not limited to) can be implemented to train the above-described depth estimation model. In a first training method, the depth estimation model is trained to generate depth maps and jointly evaluate the accuracy of the generated depth maps. Specifically, as a first part of the joint training, when a given depth map for a left stereo image is generated, the generated depth values in the depth map and the corresponding “ground truth” depth values (also referred to as depth value labels) are used to train the depth estimation model according to a first loss function. The first loss function is configured to minimize the difference between the generated depth values and the depth value labels. More specifically, the first loss function is calculated based on the output of a first output task of the depth estimation model (also referred to herein as a depth output task or a disparity output task). An output task like the first output task is often referred to as a task head for a given machine learning model (e.g., a neural network-based model), while the rest of the model is referred to as the backbone of the model. The backbone is usually shared among the task heads. The first output task can be implemented as one or more output layers of the depth estimation model.

[0028] At the same time of performing the first part of the joint training, a second part of the joint training is performed concurrently. Specifically, the above-described generated depth values and the depth value labels are used to generate depth confidence labels. Any generated confidence label indicates a corresponding depth value in the generated depth map is an accurate “ground truth” confidence level. Such a confidence level can be expressed as a probability. For example, a probability of 1 indicates the highest confidence level, and a probability of 0 indicates the lowest confidence level. In this way, a map of depth confidence labels (also referred to as a depth confidence label map) is generated for the generated depth map. Given the stereo features of the left stereo image, the depth estimation model generates a map of depth confidence scores (also referred to as a depth confidence score map or a depth confidence map) corresponding to the respective depth values in the generated depth map. Then, according to a second loss function, the depth confidence map and the depth confidence label map are used to train the depth estimation model. The second loss function is configured to minimize the difference between the depth confidence scores and the corresponding depth confidence labels. More specifically, the second loss function is calculated based on the output of a second output task of the depth estimation model (also referred to herein as a depth confidence output task). Similar to the first output task above, the second output task is often referred to as a task head for the depth estimation model, and can be implemented as one or more output layers of the depth estimation model. In this way, the depth estimation model is trained to generate depth maps and jointly evaluate the accuracy of the generated depth maps. In other words, the backbone of the depth estimation model is jointly trained through two task heads (e.g., the depth output task and the depth confidence output task). As a result of such joint training, the refinement of the common backbone of the depth estimation model with respect to one task head benefits the other task head, and thus the depth estimation model produces better and more stable outputs on both task heads.

[0029] In the second training method, the generation of the depth map and the evaluation of the accuracy of the generated depth map are trained sequentially. In contrast to the first training method, while the depth estimation model is being trained to generate the depth map, the depth estimation model is not concurrently trained to generate the depth confidence map. Specifically, the depth confidence output task does not initially exist, or is initially deactivated, frozen, or otherwise configured to not perform a forward pass operation given an input. Thus, as a first part of the sequential training, the depth estimation model is trained only to generate the depth map according to the first loss function. Once the depth estimation model is so trained, the depth output task is configured to perform only the forward pass operation. In other words, the first loss function is no longer computed, and thus the backpropagation operation via the depth output task is no longer performed. Then, as a second part of the sequential training, the depth estimation model is trained to generate the depth confidence map. Similar to the second part of the joint training described above, during each forward pass through the depth estimation model, the depth confidence map and the depth confidence label map are generated to train the depth estimation model according to the second loss function, except that the backbone of the depth estimation model is frozen (e.g., no backpropagation is performed on the backbone) during this training process. In this way, the depth estimation model is trained to generate the depth map and sequentially evaluate the accuracy of the generated depth map. In other words, the backbone of the depth estimation model is trained through the first task head (e.g., the depth output task) and then frozen during the training of the second task head (e.g., the depth confidence output task). Since the training of the second task head is separate from the training of the first task head, and the trained backbone of the depth estimation model is not retrained, there are several advantages. For example, the second task head can be trained without requiring a larger amount of training data, which would be required if the backbone of the depth estimation model were also to be retrained. Moreover, the time required to train the second task head and / or to develop downstream applications that use the trained second task head is also significantly reduced.

[0030] The disclosed techniques provide several technical advantages over previous approaches. Specifically, since the disclosed techniques remove depth values generated by the depth estimation model that have low confidence scores, the inaccuracy of the depth values is reduced. Moreover, since the disclosed techniques train the depth estimation model to estimate the depth information of a stereo image and evaluate the accuracy of the estimated depth information in the same inference process (rather than two separate processes), computational efficiency is improved.

[0031] In some embodiments, the systems and methods described herein can be performed using simulated data (e.g., simulated sensor data of simulated sensors of virtual or simulated machines) in a simulated environment (e.g., NVIDIA’s DriveSIM, NVIDIA’s ISAAC GYM, NVIDIA’s ISAAC SIM, etc.). For example, simulated sensor data can be used to perform depth estimation (e.g., using one or more machine learning models, neural networks, etc.) on objects or features within a virtual environment, and can use this information to perform operations (e.g., control, navigation, planning, etc.) associated with a virtual machine within the environment. These simulated operations can be used to test the performance of underlying algorithms, systems, and / or processes before deploying them to the real world. In some cases, simulation can be used to generate synthetic training data (e.g., training data including various scenarios, such as complex scenarios with rapid or anomalous changes in depth) in order to train the algorithms or models described herein to perform more accurate depth estimation by (simulated) stereo cameras. In some embodiments, in addition to or as an alternative to simulation, other methods can be used to generate synthetic training data. For example, synthetic training data can be generated using neural radiance fields (NERF), Gaussian spatter techniques, diffusion models, electrostatic models (e.g., Poisson Flow Generation Model (PFGM)), etc. The synthetic training data can then be processed (in addition to or as an alternative to real-world data) to determine depth information for objects and / or other features within, for example, a driving environment, a warehouse, an outdoor environment, an indoor environment, a laboratory, etc. In any of the examples, when a simulated environment is used for testing, validation, training, etc., one or more light transport algorithms (e.g., ray tracing algorithms and / or path tracing algorithms) can be used to render or otherwise generate the simulated environment and / or associated training data. In some embodiments, the simulated environment and / or one or more objects, features, or components thereof can be generated or managed within a three-dimensional (3D) content collaboration platform (e.g., NVIDIA’s OMNIVERSE) for industrial digitization, generative physics AI, and / or other use cases, applications, or services. For example, the content collaboration platform or system can include a system that manages objects, features, scenes, etc. in simulated environments, digital environments, etc. using Universal Scene Description (USD) (e.g., OpenUSD) data. The platform can include realistic physics simulation, e.g., using NVIDIA’s PhysX SDK, in order to simulate realistic physics and physical interactions with the simulations hosted by the platform. The platform can integrate OpenUSD along with ray tracing / path tracing / light transport simulation (e.g., NVIDIA’s RTX rendering technology) into software tools and simulation workflows for building, training, deploying, or testing AI systems, e.g., systems for testing, validation, training (e.g., machine learning models, neural networks, etc.), and / or other tasks related to automobiles, robots, machines, or other applications.

[0032] In some embodiments, remote control or teleoperation systems can be used to perform teleoperation or remote control of vehicles or other machines (e.g., robots, AMRs, etc.). For example, the systems and methods described herein can be used to identify depth information of objects and / or features of an environment, which can be included in a visualization or mapping of the environment to assist a remote operator in controlling (or providing waypoints or other control or navigation instructions) an autonomous or semi-autonomous machine through the environment.

[0033] In some examples, the machine learning models (e.g., deep neural networks, language models, LLMs, VLMs, multi-modal language models, perception models, tracking models, fusion models, transformer models, diffusion models, encoder-only models, decoder-only models, encoder-decoder models, neural rendering field (NERF) models, etc.) described herein can be packaged as microservices, such as inference microservices (e.g., NVIDIA NIM), which can include containers (e.g., operating system (OS) level virtualization packages) that can include an application programming interface (API) layer, a server layer, a runtime layer, and / or a model “engine.” For example, an inference microservice can include the container itself and one or more models (e.g., weights and biases). In some cases, such as when the machine learning model is small enough (e.g., has few enough parameters), the model can be included within the container itself. In other examples, such as in cases where the model is large, the model can be hosted / stored in the cloud (e.g., in a data center) and / or can be hosted locally and / or at the edge (e.g., on a local server or computing device, but outside of the container). In such embodiments, the model can be accessed via one or more APIs (e.g., REST APIs). Thus, in some embodiments, the machine learning models described herein can be deployed as inference microservices to accelerate the deployment of models on any cloud, data center, or edge computing system while ensuring that data is secure. For example, an inference microservice can include one or more APIs, pre-configured containers for ease of deployment, an optimized inference engine (e.g., execution software built using standardized AI model deployment (e.g., NVIDIA’s Triton Inference Server), and / or one or more APIs for high-performance deep learning inference, which can include an inference runtime and model optimization that can provide low latency and high throughput for production applications (e.g., NVIDIA’s TensorRT)), and / or enterprise management data for telemetry (e.g., including identity, metrics, health checks, and / or monitoring). The machine learning models described herein can be included as part of a microservice along with acceleration infrastructure, enabling deployment with a single command and / or orchestration and auto-scaling (e.g., from a single device to data center scale) using container orchestration systems on the acceleration infrastructure. Thus, an inference microservice can include a machine learning model (e.g., that has been optimized for high-performance inference), an inference runtime software for executing the machine learning model and providing an output / response to an input (e.g., a user query, a prompt, etc.), and enterprise management software for providing health checks, identity, and / or other monitoring. In some embodiments, an inference microservice can include software for performing in-place replacement and / or updates to the machine learning model. Upon replacement or update, the software performing the replacement / update can maintain user configurations of the inference runtime software and the enterprise management software.

[0034] Figure 1 A system 100 configured to implement one or more aspects of the various embodiments is shown. As illustrated, system 100 includes a machine learning server 110, a data store 120, and a computing device 140, which communicate through a network 130, which can be a wide area network (WAN), such as the Internet, a local area network (LAN), and / or any other suitable network.

[0035] As shown, a model trainer 116 executes on a processor 112 of the machine learning server 110 and is stored in a system memory 114 of the machine learning server 110. The processor 112 receives user input from input devices such as a keyboard, a mouse, a joystick, a touch screen, a VR / AR / MR device, and / or a microphone. In operation, the processor 112 is the main processor of the machine learning server 110, controlling and coordinating the operation of the other system components. In particular, the processor 112 can issue commands that control the operation of a graphics processing unit (GPU) (not shown), which contains circuitry optimized for graphics and video processing, including video output circuitry, for example. The GPU can transfer pixels to a display device, which can be any conventional cathode ray tube, liquid crystal display, light emitting diode display, or the like.

[0036] The system memory 114 of the machine learning server 110 stores content, such as software applications and data, for use by the processor 112 and the GPU. The system memory 114 can be any type of memory that is capable of storing data and software applications, such as random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or Flash ROM), or any suitable combination of the above. In some embodiments, a storage device (not shown) can supplement or replace the system memory 114. The storage device can include any number and type of external memory accessible by the processor 112 and / or the GPU. For example, but not limited to, the storage device can include a secure digital card, an external flash memory, a portable compact disc read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0037] It should be understood that the machine learning server 110 shown herein is illustrative and can be varied and modified. For example, the number of processors 112, the number of GPUs, the amount of system memory 114, and the number of applications included in the system memory 114 can be modified as desired. Furthermore, the machine learning server 110 can be modified as desired to include additional components not shown, such as additional processors, additional GPUs, additional system memories, additional storage devices, and / or additional input / output devices. Figure 1connections between the various units in the system 100. In some embodiments, any combination of the processor 112, the system memory 114, and the GPU can be replaced with any type of virtual computing system, distributed computing system, or cloud computing environment (e.g., a public cloud, a private cloud, or a hybrid cloud).

[0038] In some embodiments, the model trainer 116 is configured to train one or more machine learning models, including the depth estimation model 146. The depth estimation model 146 is a machine learning model that generates a depth map given a stereo image pair and concurrently evaluates the accuracy of the generated depth map. The depth estimation model 146 is discussed in more detail below in connection with Figure 2 An example architecture of the depth estimation model 146 is discussed in more detail below. The depth estimation model 146 is discussed in more detail below in connection with Figure 3 and Figures 4A-4B Techniques for training the model are discussed in more detail below. The training data and / or trained machine learning models, including the depth estimation model 146, can be stored in the data store 120. In some embodiments, the data store 120 can include any one or more storage devices, such as fixed disk drives, flash drives, optical storage, network attached storage (NAS), and / or storage area network (SAN). Although shown as being accessible over the network 130, in some embodiments, the machine learning server 110 can include the data store 120.

[0039] Once trained, the depth estimation model 146 can be deployed for inference, e.g., to generate a depth map given a stereo image pair and concurrently evaluate the accuracy of the generated depth map. Illustratively, a depth estimation application 145 that utilizes the depth estimation model 146 is stored in the system memory 144 and executed on the processor 142 of the computing device 140. In some embodiments, the components of the computing device 140, including the system memory 144 and the processor 142, can be similar to the corresponding components of the machine learning server 110.

[0040] It should be understood that the system 100 shown herein is illustrative and can be varied and modified. For example, the number of machine learning servers and computing devices can be modified as desired. In addition, functionality included in any application can be divided into any number of applications or other software that is stored and executed by any number of computing systems located in any number of physical locations.

[0041] Figure 2 is an example inference process for a depth estimation model according to various embodiments. As shown, such a process is performed at a computing device 140 that includes a processor 142 and a system memory 144. The computing device 140 can be a server, a desktop computer, a laptop computer, a tablet computer, a mobile device, or any other type of computing device. Figure 1 is an example inference process for a depth estimation model according to various embodiments. As shown, such a process is performed at a computing device 140 that includes a processor 142 and a system memory 144. The computing device 140 can be a server, a desktop computer, a laptop computer, a tablet computer, a mobile device, or any other type of computing device. Figure 1depth estimation application 145. The depth estimation model 146 includes a first feature extractor 212, a second feature extractor 214, a feature correlation engine 232 (also referred to as cost volume computation), a depth estimation engine 242, and a depth accuracy assessment engine 243. Given the left stereo image 202 and the right stereo image 204, the depth estimation model 146 can generate a depth map 248 representing depth information of pixels in one of the stereo images, and the depth accuracy assessment engine 243 can concurrently generate a depth confidence map 250 with confidence scores representing probabilities that the depth information in the generated depth map is accurate. In some embodiments, the depth estimation model 146 is implemented as one or more neural networks (NNs) (e.g., deep learning neural networks (DNNs)).

[0042] The first feature extractor 212 and the second feature extractor 214 can receive the left stereo image 202 and the right stereo image 204, respectively, as input and generate a left set of feature maps 222 and a right set of feature maps 224, respectively. In at least one embodiment, the depth estimation model 146 is configured to generate a depth map 248 for the left stereo image 202 (such an embodiment is referred to hereinafter as a left stereo image embodiment). Each of the first feature extractor 212 and the second feature extractor 214 can use the same set of one or more convolutional layers to generate a respective set of feature maps. For example, given the left stereo image 202, the first feature extractor 212 can use convolutional layers to extract features from the left stereo image 202 using a set of convolutional filters (also referred to as filters or kernels). Each of the set of convolutional filters is used to extract a different feature from the left stereo image 202 and output a corresponding left feature map. Examples of features include edges, textures, shapes, and higher-level features such as object semantics and classes. In this way, a set of left feature maps, e.g., the left set of feature maps 222, can be extracted from the left stereo image 202 using the set of convolutional filters. Each feature map in the left set of feature maps 222 is typically represented as a 2D data structure (e.g., a 2D vector or tensor) where each location in the map includes a value (e.g., a pixel value) indicating the presence, absence, or level of a given feature. Each feature map is typically referred to as a feature channel or a channel. All channels are typically collectively referred to as a channel dimension. In this way, the features extracted from the left stereo image 202 are represented in a 3D structure. For example, assuming there are C channels and each feature map has a width of W and a height of H (e.g., a dimension of W x H), then a set of such feature maps has a dimension of C x W x H.

[0043] Given the right stereo image 204, the second feature extractor 214 can similarly extract a set of right feature maps 224 from the right stereo image 204. In some embodiments, the first and second feature extractors 212, 214 are implemented using a CNN or a variant of a CNN. In such embodiments, the two feature extractors can share network weights such that feature maps are extracted from them in a consistent manner.

[0044] Given the set of left feature maps 222 and the set of right feature maps 224, the feature correlation engine 232 can compute feature correlations 234 between the two sets of feature maps. Continuing with the left stereo image embodiment herein, given the set of left feature maps 222 and the set of right feature maps 224, in at least one embodiment, the feature correlation engine 232 computes, within each channel, the correlation between all pixels in a given row in the left feature map and all pixels in the corresponding row in the right feature map (e.g., using matrix multiplication). Since the pixels in a column are located in different rows of the feature maps, in at least one embodiment, the feature correlation engine 232 computes the correlation between all columns in the left feature map and all columns in the right feature map. More specifically, within each channel, the feature correlation engine 232 computes the correlation between a given column in the left feature map and all columns in the right feature map to generate a correlation map for that given column in the left feature map. Since the number of columns in the right feature map is the width of the right feature map, the correlation map thus generated has the dimensions of the right feature map, i.e., W x H. Moreover, since the number of columns in the left feature map is the width of the left feature map, the number of correlation maps formed within each channel is W. Thus, all correlation maps (not shown) across all channels form a structure of dimensions C x W x W x H.

[0045] As a further optimization, the feature correlation engine 232 can compress the generated correlation maps to improve computational efficiency. Continuing with the left stereo image embodiment herein, in at least one embodiment, the feature correlation engine 232 compresses the generated correlation maps across the channel dimension. More specifically, the correlation maps formed using corresponding columns in the left feature maps are added across all channels (e.g., using matrix addition). For example, the correlation maps generated using the first column in the left feature maps within each channel of the left feature map set 222 are added across all channels. Since there are a number W of columns in the left feature maps, a number W of compressed correlation maps (not shown) are generated, where each such map has the dimensions of the original correlation map, i.e., W x H. Such a compression operation merges all channels into a single channel and effectively eliminates the channel dimension of the original correlation map. Thus, the compressed correlation maps have dimensions of W x W x H. The compressed correlation maps can be referred to as W correlation channels of the compressed correlation maps, each having dimensions of W x H (the same as the dimensions of each feature map in the left feature map set 222).

[0046] As a further optimization, the feature correlation engine 232 can perform a masking operation to further improve computational efficiency and accuracy. Specifically, since all columns of the right feature map are used for the feature correlation computation, certain locations in the right feature map that can not be used for disparity prediction are also included in the computation. More specifically, according to the inherent property of a stereo image pair, the location in the right feature map that corresponds to a given location in the left feature map is always to the left of the given location. That is, any location in the right feature map that is to the right of the given location cannot correspond to the given location in the left feature map and thus is not used for disparity prediction. In fact, the disparity predicted based on these locations in the right feature map and the given location in the left feature map would yield an unrealistic negative disparity value. Continuing with the left stereo image embodiment herein, in at least one embodiment, the feature correlation engine 232 applies a masking operation (also referred to as bit masking or location masking) to each compressed correlation map to remove the compressed correlations that are not used to predict the depth map 248 of the left stereo image 202. During the masking operation, a different mask (also referred to as a correlation filter) is generated for each compressed correlation map based on the spatial locations of the columns in the left feature map for which the corresponding correlation map is generated. Since the mask is computed based on the spatial locations of the columns rather than the pixel values in these columns, the computational cost of computing the mask remains constant and negligible regardless of the magnitudes of the pixel values in the left stereo image 202 and the right stereo image 204. Once the masking operation is complete, the feature correlation engine 232 outputs the masked correlation maps as the feature correlations 234. In this way, unnecessary downstream processing of compressed correlations that cannot contribute to the generation of the depth map 248 is avoided. Moreover, since the masked correlation maps do not change the dimensions of the compressed correlation maps, they can be referred to as W correlation channels of the masked correlation maps, each with dimensions of W x H, just like their corresponding compressed correlation maps Figure 1 In some embodiments, the feature correlation engine 232 can apply one or more convolutional layers to the W correlation channels of the compressed correlation maps to extract higher-level correlation features from the compressed correlation maps. This approach can reduce the number of correlation channels, thereby helping to improve the computational efficiency of the downstream processing related to the compressed correlation maps.

[0047] Given the feature correlations 234 and the left feature map set 222, the depth estimation engine 242 can generate the depth map 248, and the depth accuracy assessment engine can concurrently generate the depth confidence map 250. The depth estimation engine 242 includes an image segmentation task 244 and a disparity output task 147.

[0048] Given the left set of feature maps 222 and the feature correlations 234, the image segmentation task 244 can extract higher-level features of the left stereo image 202, e.g., higher-level features that contribute to estimating the disparity between each pixel in the left stereo image 202 and a corresponding pixel in the right stereo image 204 (hereinafter referred to as stereo features). The image segmentation task 244 can be implemented as a Unet architecture that includes an encoder and a decoder. In such embodiments, the correlation channels of the masked correlation map and the feature channels of the left feature maps are combined into one combined channel dimension, and the combination of the encoder and the decoder extracts higher-level features related to disparity from the combined channel dimension. Such higher-level features are referred to herein as stereo features 245. The stereo features 245 can have a structure similar to that of the feature correlations 234 or the left set of feature maps. For example, the stereo features 245 can be a given number of stereo feature map channels, where each stereo feature map has a dimension of W x H. In at least one embodiment, the encoder can be implemented as a residual network (e.g., Res-Net 18), and the decoder can be implemented as one or more convolutional layers.

[0049] Given the stereo features 245, the disparity output task 147 can generate a depth map 248 for the left stereo image 202. In at least one embodiment, the disparity output task 147 can compress the channels in the stereo features 245 into a single channel (e.g., using a convolutional layer) to generate a disparity map in 2D structure. In some embodiments, the left stereo image 202 and the right stereo image 204 are down-sampled before being provided to the first feature extractor 212 and the second feature extractor 214. In such embodiments, the output of the disparity output task 147 is up-sampled to match the resolution of the left stereo image 202 before generating a disparity map for the left stereo image 202. Given the disparity map, the disparity output task 147 can generate a depth map 248 based on the disparity map using the stereo camera configuration and / or intrinsics (e.g., focal length and baseline) according to the following equation: The disparity output task 147 is sometimes referred to as a segmentation task head (or segmentation head) of the depth estimation model 146.

[0050] When the disparity output task 147 generates the depth map 248, a depth confidence output task 148 in the depth accuracy evaluation engine 243 can concurrently generate a depth confidence map 250 given the stereo features 245, e.g., to evaluate the accuracy of the depth map 248. The depth confidence map 250 includes pixel locations that correspond to the pixel locations of the depth map 248. Each pixel location in the depth confidence map 250 includes a confidence score for the depth value in the corresponding pixel location in the depth map 248. For example, the confidence score can be expressed as a probability that the corresponding depth value is accurate. In at least one embodiment, the depth confidence output task 148 is implemented as a feed-forward network that includes one or more convolutional layers. For example, the depth confidence output task 148 can use a convolutional layer to compress the multiple channels in the stereo features 245 into a single channel to generate a 2D structure. Given the compressed stereo features in the 2D structure, the depth confidence output task 148 can then apply an activation function (e.g., a sigmoid function) to generate the depth confidence map 250 that includes the confidence scores for the depth values in the depth map 248. The depth confidence output task 148 is sometimes referred to as a confidence evaluation task head for the depth estimation model 146. In this way, the depth estimation model 146 generates the depth map 248 and concurrently evaluates the accuracy of the depth map 248.

[0051] Given the depth map 248 and the depth confidence map 250, the post-processing 252 updates the depth values for one or more pixel locations in the depth map 248 based on the depth confidence map 250. In particular, the depth estimation model 146 can determine that one or more confidence scores in the depth confidence map 250 indicate that the corresponding depth values in the depth map 248 are inaccurate (e.g., a low confidence score that is below an acceptable threshold). Upon making such a determination, the post-processing 252 can cause an updated depth map 254 to be generated. In the updated depth map 254, the low confidence scores are removed from the original depth map 248 (e.g., by applying the depth confidence map 250 and an acceptable confidence score threshold to the depth map 248 as a mask to filter out the low confidence scores) or otherwise handled so that they are not provided to downstream processing (e.g., converted to an indicator (e.g., a zero) that indicates that such confidence scores are not to be used. In some embodiments, the depth estimation model 146 can provide the original depth map 248 and the depth confidence map 250 directly to downstream processing (e.g., in the depth estimation application 145) so that the depth values with low confidence scores can be removed there.

[0052] Figure 3 An example process for training a depth estimation model 146 according to various embodiments is shown. As shown, such a process can be performed by a training system 260 that includes a training engine 262 and a training data store 264. The training engine 262 can be implemented as a computer system that includes one or more processors and one or more memory devices. The training engine 262 can be implemented as a single computer system or as a distributed computer system that includes multiple computer systems that are communicatively coupled via a network. The training engine 262 can be implemented as a cloud-based computer system that is accessible via the Internet or as a computer system that is accessible via a local network (e.g., a local area network, a wide area network, a private network, a virtual private network, a cloud-based network, etc.). The training engine 262 can be implemented as a computer system that is operated by a third party (e.g., a cloud computing service provider) or as a computer system that is operated by an entity that is independent of the third party (e.g., a user of the depth estimation application 145). Figure 1 The training engine 262 can be implemented as a computer system that includes one or more processors and one or more memory devices. The training engine 262 can be implemented as a single computer system or as a distributed computer system that includes multiple computer systems that are communicatively coupled via a network. The training engine 262 can be implemented as a cloud-based computer system that is accessible via the Internet or as a computer system that is accessible via a local network (e.g., a local area network, a wide area network, a private network, a virtual private network, a cloud-based network, etc.). The training engine 262 can be implemented as a computer system that is operated by a third party (e.g., a cloud computing service provider) or as a computer system that is operated by an entity that is independent of the third party (e.g., a user of the depth estimation application 145).Figure 1 the depth estimation model 146 to operate as described above. In particular, the process trains the depth estimation model 146 to generate depth maps 348 according to a depth loss function 360 and depth confidence maps 350 according to a depth confidence loss function 364 in a joint manner. Figure 2

[0053] In at least one embodiment, given the left stereo image 302 and the right stereo image 304, the depth estimation model 146 can perform a forward pass to generate a depth map 348 and concurrently generate a depth confidence map 350, as shown in Figure 2

[0054] At the same time that the depth estimation model 146 is trained according to the depth loss function 360 through the disparity output task 147, the depth estimation model 146 is concurrently trained according to the depth confidence loss function 364 through the depth confidence output task 148. In particular, given the depth confidence map 350 (which is also generated as part of the forward pass performed by the depth estimation model 146), a second loss can be computed according to the depth confidence loss function 364. The depth confidence loss function 364 is configured to minimize the difference between the confidence scores in the depth confidence map 350 and the “ground truth” confidence levels in the depth confidence label map 363. The depth confidence loss function 364 can be implemented as any suitable classification loss function (e.g., a binary cross-entropy (BCE) loss function).

[0055] The depth confidence label map 363 can be generated by the depth confidence label computation 362 given the depth values in the depth map 348 and the corresponding depth value labels described herein as input. Each confidence label in the depth confidence label map 363 represents a confidence level that the corresponding depth value in the depth map 348 is accurate. For example, a probability of 1 indicates a highest confidence level and a probability of 0 indicates a lowest confidence level. For example, the confidence labels can be generated according to the following equation:

[0056] ​​sigmoid(a-clamp(EPE, 0, b)) (1)

[0057] where EPE represents the expected predictor error and is equal to the absolute value of the difference between the generated depth value in the depth map 348 and the corresponding depth value label, clamp represents a function that limits its first input parameter between its second and third input parameters, a and b are hyperparameters, and sigmoid represents a sigmoid function that scales its input to a range between 0 and 1. For example, when a = 3 and b = 6, equation (1) is configured to generate a confidence label with a value of 0.5 when EPE is equal to 3, a confidence label with a value close to 1 when the value of EPE is close to 0, and a confidence label with a value close to 0 when the value of EPE is greater than 6. The values of the hyperparameters a and b can be set to any other suitable pair of numbers to generate confidence labels in different implementations.

[0058] Given the computed second loss, backpropagation (not shown) can be performed with respect to the configurations in the depth estimation model 146 (e.g., the weights and biases in the model). In this way, the depth estimation model 146 is being trained through the depth confidence output task 148 while being trained through the disparity output task 147. In other words, the backbone of the depth estimation model 146 is being jointly trained through the two task heads (i.e., the disparity output task 147 and the depth confidence output task 148).

[0059] Figures 4A-4B An example process of training the depth estimation model 146 according to various embodiments is shown. As shown, in a first portion of the process, the depth estimation model 146 is trained to generate depth maps 348 according to a depth loss function 360, as described in Figure 1 The model trainer 116 trains the depth estimation model 146 to operate as described in Figure 2 Specifically, the process trains the depth estimation model 146 to sequentially generate depth maps 348 according to a depth loss function 360 and generate depth confidence maps 350 according to a depth confidence loss function 364. Specifically, in a first portion of the process, the depth estimation model 146 is trained to generate depth maps 348 according to a depth loss function 360, as described in Figure 3 Once the depth estimation model 146 is so trained, in a second portion of the process, the model is trained to generate depth confidence maps 350, as described in Figure 3

[0060] Figure 4A ​A first portion of an example training process is shown. The depth confidence output task 148 is deactivated, frozen, or otherwise configured to not perform a forward pass operation given an input. Specifically, given an input, the depth confidence output task 148 does not generate a depth confidence map 350 to cause the depth confidence loss function 364 to compute a loss, as indicated by the strikethrough symbol 402. Similarly, given an input, the depth confidence label computation 362 is deactivated, frozen, or otherwise configured to not generate an output to cause the depth confidence loss function 364 to compute a loss, as indicated by the strikethrough symbol 404. In some embodiments, the depth confidence loss function 364 can be configured to not compute a loss given an input. In such embodiments, the depth confidence output task 148 and / or the depth confidence label computation 362 can remain activated or otherwise configured to perform operations as usual given an input. In some other embodiments, the depth confidence loss function 364 can be configured to compute a loss given an input, but a backpropagation operation is not configured to be performed to train the depth estimation model based on the computed loss. In such embodiments, the depth confidence output task 148 and / or the depth confidence label computation 362 can also remain activated or otherwise configured to perform operations as usual given an input. In this way, the depth estimation model 146 is trained only to generate depth maps 348 in the first portion of the training process.

[0061] Figure 4B A second portion of an example training process is shown. Once the depth estimation model 146 has been trained to generate depth maps 348, the depth loss function 360 is deactivated, frozen, or otherwise configured to not compute a loss given an input. Specifically, given a depth map 348, the depth loss function 360 does not compute a loss to cause a backpropagation operation to be performed to train the depth estimation model 146 by the disparity output task 147, as indicated by the strikethrough symbol 406. In some embodiments, the depth loss function 360 can be configured to compute a loss, but a backpropagation operation is not configured to be performed to train the depth estimation model 146 based on the computed loss. In other words, with respect to the disparity output task 147, the depth estimation model 146 is configured to perform only forward pass operations. On the other hand, the depth confidence loss function 364 can be configured to compute a loss, but only a backpropagation operation is performed with respect to the depth confidence map 350. In other words, with respect to the depth confidence output task 148, the depth estimation model 146 is trained only with respect to the depth accuracy evaluation engine 243 (and not the backbone of the depth estimation model 146). In this way, the depth estimation model 146 is trained only to generate depth confidence maps 350 using forward passes of the depth estimation model 146 trained with respect to the disparity output task 147 in the second portion of the training process.

[0062] Now refer to Figure 5 Each block of the method 500 described herein comprises a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, the various functions can be implemented by a processor executing instructions stored in a memory. The methods can also be embodied as computer-usable instructions stored on a computer storage medium. The methods can be provided by a standalone application, a service, or a hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. Furthermore, the method 500 is about Figure 1 However, these methods may additionally or alternatively be performed by any system or any combination of systems, including but not limited to the systems described herein.

[0063] Figure 5 is a diagram showing some embodiments of the present disclosure for Figure 2 Flowchart of method 500. Figure 5 As shown, method 500 begins at operation 502, where a depth estimation application (e.g., Figure 1 The depth estimation application 145) generates a depth map associated with the first image based on at least stereo features of the first image in the stereo image pair. The stereo features are generated based on at least a first set of feature maps for the first image and feature correlations calculated between the first set of feature maps and a second set of feature maps for the second image in the stereo image pair. In some embodiments, the stereo features of the first image in the stereo image pair are associated with disparity between corresponding pixels in the first image and the second image in the stereo image pair. In some embodiments, generating the depth map associated with the first image includes applying one or more convolutional layers to the stereo features.

[0064] At operation 504, the depth estimation application generates a confidence map that represents a probability that depth values ​​in the generated depth map are accurate based on at least the stereo features of the first image. In some embodiments, generating the confidence map includes applying one or more convolutional layers and activation functions to the stereo features.

[0065] At operation 506, the depth estimation application updates one or more portions of the generated depth map based at least on the confidence map. In some embodiments, updating one or more portions of the generated depth map based at least on the confidence map includes removing one or more original depth values ​​from the depth map using the confidence map as a mask.

[0066] In some embodiments, the method 500 is performed using a machine learning model. In some such embodiments, the machine learning model is jointly trained to generate a depth map and a confidence map corresponding to the depth map. In some such embodiments, the machine learning model is trained to generate the confidence map after being trained to generate the depth map.

[0067] At operation 508, the depth estimation application performs one or more operations associated with the autonomous or semi-autonomous machine based at least on the updated generated depth map.

[0068] The systems and methods described herein can be used by, but are not limited to, non-autonomous vehicles, semi-autonomous vehicles (e.g., in one or more adaptive driver assistance systems (ADAS)), manned and unmanned robots or robotic platforms, warehouse vehicles, off-road vehicles, vehicles coupled to one or more trailers, spacecraft, watercraft, shuttles, emergency response vehicles, motorcycles, electric or motorized bicycles, aircraft, engineering vehicles, submarines, drones, and / or other vehicle types. Further, the systems and methods described herein can be used for various purposes such as, but not limited to, machine control, machine motion, machine driving, synthetic data generation, model training, perception, augmented reality, virtual reality, mixed reality, robotics, safety and supervision, simulation and digital twin, autonomous or semi-autonomous machine applications, deep learning, environment simulation, object or actor simulation and / or digital twin, data center processing, conversational AI, light transport simulation (e.g., ray tracing, path tracing, etc.), collaborative content creation of 3D assets, cloud computing, and / or any other suitable application.

[0069] The disclosed embodiments can be included in a variety of different systems, such as automotive systems (e.g., control systems for autonomous or semi-autonomous machines, perception systems for autonomous or semi-autonomous machines), systems implemented using robots, aviation systems, medical systems, boating systems, smart area monitoring systems, systems for performing deep learning operations, systems for performing simulation operations, systems for performing digital twin operations, systems implemented using edge devices, systems containing one or more virtual machines (VMs), systems for performing synthetic data generation operations, systems implemented at least partially in data centers, systems for performing conversational AI operations, systems for performing light transport simulation, systems for performing collaborative content creation of 3D assets, systems implemented at least partially using cloud computing resources, and / or other types of systems.

[0070] Clause 1. In some embodiments, a method comprises: generating, based at least on stereo features of a first image of a stereo image pair, a depth map associated with the first image, the stereo features generated based at least on a first set of feature maps of the first image and a computed feature correlation between the first set of feature maps and a second set of feature maps of a second image of the stereo image pair; generating a confidence map representing a probability that a depth value in the generated depth map is accurate; updating one or more portions of the generated depth map based at least on the confidence map; and performing one or more operations associated with an autonomous or semi-autonomous machine based at least on the generated depth map after the updating.

[0071] Clause 2. The method of clause 1, wherein the stereo features of the first image of the stereo image pair are associated with a disparity between corresponding pixels in the first image and the second image of the stereo image pair.

[0072] Clause 3. The method of clause 1 or 2, wherein generating the depth map associated with the first image comprises: applying one or more convolutional layers to the stereo features.

[0073] Clause 4. The method of any of clauses 1-3, wherein generating the confidence map comprises: applying one or more convolutional layers and an activation function to the stereo features.

[0074] Clause 5. The method of any of clauses 1-4, wherein the activation function is configured to output a value between 0 and 1, inclusive of 0 and inclusive of 1.

[0075] Clause 6. The method of any of clauses 1-5, wherein the method is performed using a machine learning model, and wherein the machine learning model is jointly trained to generate a depth map and a confidence map corresponding to the depth map.

[0076] Clause 7. The method of any of clauses 1-6, wherein the method is performed using a machine learning model, and wherein the machine learning model is trained to generate a confidence map after being trained to generate a depth map.

[0077] Clause 8. The method of any of clauses 1-7, wherein updating the one or more portions of the generated depth map based at least on the confidence map comprises: removing one or more original depth values from the depth map using the confidence map as a mask.

[0078] Clause 9. The method of any of clauses 1-8, wherein the first set of feature maps corresponds to a set of feature channels.

[0079] Clause 10. In some embodiments, the at least one processor includes one or more circuits to: generate, based at least on stereo features of a first image of a stereo image pair, a depth map associated with the first image, the stereo features generated based at least on a first set of feature maps of the first image and a computed feature correlation between the first set of feature maps and a second set of feature maps of a second image of the stereo image pair; generate a confidence map representing a probability that a depth value in the generated depth map is accurate; update one or more portions of the generated depth map based at least on the confidence map; and perform one or more operations associated with an autonomous or semi-autonomous machine based at least on the generated depth map after the update.

[0080] Clause 11. The at least one processor of clause 10, wherein the processor is included in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system to perform simulation operations; a system to perform digital twin operations; a system to perform optical transport simulation; a system to perform collaborative content creation of 3D assets; a system to perform deep learning operations; a system implemented using edge devices; a system to generate or present at least one of virtual reality content, augmented reality content, or mixed reality content; a system implemented using robots; a system to perform conversational AI operations; a system implementing one or more large language models; a system implementing one or more visual language models (VLMs); a system implementing one or more multi-modal language models (MMLMs); a system implementing one or more machine learning models used as inference microservices, the inference microservices including the one or more machine learning models and one or more operating system (OS) level virtualization packages; a system to generate synthetic data; a system containing one or more virtual machines (VMs); a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources.

[0081] Clause 12. The at least one processor of any of clauses 1-11, wherein the stereo features of the first image of the stereo image pair are associated with a disparity between corresponding pixels in the first image and the second image of the stereo image pair.

[0082] Clause 13. The at least one processor of any of clauses 1-12, wherein generating the depth map associated with the first image includes applying one or more convolutional layers to the stereo features.

[0083] Clause 14. The at least one processor of any of clauses 1-13, wherein generating the confidence map comprises applying one or more convolutional layers and activation functions to the stereo features.

[0084] Clause 15. The at least one processor of any of clauses 1-14, wherein the activation function is configured to output values between 0 and 1, inclusive.

[0085] Clause 16. The at least one processor of any of clauses 1-15, wherein updating the one or more portions of the generated depth map based at least on the confidence map comprises removing one or more original depth values from the depth map using the confidence map as a mask.

[0086] Clause 17. The at least one processor of any of clauses 1-16, wherein the one or more circuits execute a machine learning model, and wherein the machine learning model is jointly trained to generate a depth map and a confidence map corresponding to the depth map.

[0087] Clause 18. The at least one processor of any of clauses 1-17, wherein the one or more circuits execute a machine learning model, and wherein the machine learning model is trained to generate a confidence map after being trained to generate a depth map.

[0088] Clause 19. A system comprising: one or more processors to cause performance of one or more control operations related to a machine based at least on a final depth map generated using one or more stereo cameras of the machine, the final depth map generated based at least on: computation of an initial depth map and a confidence map corresponding to the initial depth map using one or more machine learning models, and adjustment of one or more depth values of the initial depth map using the confidence map.

[0089] Clause 20. The system of clause 19, wherein the system is included in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; a system for performing optical transport simulation; a system for performing collaborative content creation of 3D assets; a system for performing deep learning operations; a system implemented using an edge device; a system for generating or presenting at least one of virtual reality content, augmented reality content, or mixed reality content; a system implemented using a robot; a system for performing conversational AI operations; a system implementing one or more large language models; a system implementing one or more visual language models (VLMs); a system implementing one or more multi-modal language models (MMLMs); a system implementing one or more machine learning models used as inference microservices, the inference microservices including the one or more machine learning models and one or more operating system (OS) level virtualization packages; a system for generating synthetic data; a system containing one or more virtual machines (VMs); a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources.

[0090] Any and all combinations of any of the claimed elements and / or any of the elements or clauses described in this application in any way are within the intended scope of the disclosure and protection.

[0091] Example autonomous vehicle

[0092] Figure 6Ais a diagram of an example autonomous vehicle 600 according to some embodiments of the present disclosure. The autonomous vehicle 600 (or “vehicle 600” as referred to herein) can include, but is not limited to, a passenger vehicle such as a car, truck, bus, first responder vehicle, shuttle, electric or motorized bicycle, motorcycle, fire truck, police car, ambulance, boat, construction vehicle, underwater vehicle, robotic vehicle, drone, airplane, vehicle coupled to a trailer (e.g., a semi-tractor-trailer truck for hauling cargo), and / or other types of vehicles (e.g., vehicles that are driverless and / or that accommodate one or more passengers). Autonomous vehicles are often described in terms of levels of automation, defined by the National Highway Traffic Safety Administration (NHTSA) under the U.S. Department of Transportation, and Society of Automotive Engineers (SAE) “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles” (Standard No. J3016-201806, published on June 15, 2018, Standard No. J3016-201609, published on September 30, 2016, and prior and future versions of this standard). The vehicle 600 can implement functionality according to one or more of Levels 3-5 of autonomous driving. The vehicle 600 can be capable of having functionality that complies with one or more of Levels 1-5 of autonomous driving. For example, according to embodiments, the vehicle 600 can have driver-assistance (Level 1), partial automation (Level 2), conditional automation (Level 3), high automation (Level 4), and / or full automation (Level 5). The term “autonomous” as used herein can include any and / or all types of autonomy of the vehicle 600 or other machines, such as fully autonomous, highly autonomous, conditionally autonomous, partially autonomous, providing assisted autonomy, semi-autonomous, primarily autonomous, or other designations.

[0093] The vehicle 600 can include a chassis, a body, wheels (e.g., 2, 4, 6, 8, 18, etc.), tires, axles, and other components of a vehicle. The vehicle 600 can include a propulsion system 650, such as an internal combustion engine, a hybrid power plant, an all-electric motor, and / or other propulsion system types. The propulsion system 650 can be connected to a drivetrain of the vehicle 600, which can include a transmission to effectuate propulsion of the vehicle 600. The propulsion system 650 can be controlled in response to receiving signals from a throttle / accelerator 652.

[0094] When the propulsion system 650 is operating (e.g., when the vehicle is in motion), a steering system 654 including a steering wheel can be used to guide the vehicle 600 (e.g., along a desired path or route). The steering system 654 can receive signals from a steering actuator 656. For full automation (Level 5) functionality, the steering wheel can be optional.

[0095] The brake sensor system 646 can be used to operate the vehicle brakes in response to signals received from the brake actuator 648 and / or brake sensors.

[0096] The one or more controllers 636 can include one or more system on a chip (SoC) 604 Figure 6C ) and / or one or more GPUs that can provide signals (e.g., representative of commands) to one or more components and / or systems of the vehicle 600. For example, the one or more controllers can send signals through one or more brake actuators 648 to operate the vehicle brakes, through one or more steering actuators 656 to operate the steering system 654, through one or more throttle / accelerator 652 to operate the propulsion system 650. The one or more controllers 636 can include one or more on-board (e.g., integrated) computing devices (e.g., supercomputers) that process sensor signals and output operational commands (e.g., signals representative of commands) to enable autonomous driving and / or assist a human driver in driving the vehicle 600. The one or more controllers 636 can include a first controller 636 for autonomous driving functions, a second controller 636 for functional safety functions, a third controller 636 for artificial intelligence functions (e.g., computer vision), a fourth controller 636 for infotainment functions, a fifth controller 636 for redundancy in emergency situations, and / or other controllers. In some examples, a single controller 636 can handle two or more of the above functions, two or more controllers 636 can handle a single function, and / or any combination thereof.

[0097] One or more controllers 636 can provide signals to control one or more components and / or systems of vehicle 600 in response to sensor data (e.g., sensor inputs) received from one or more sensors. The sensor data can be received from, for example and without limitation, one or more global navigation satellite system (“GNSS”) sensors 658 (e.g., one or more global positioning system sensors), one or more radar sensors 660, one or more ultrasonic sensors 662, one or more lidar sensors 664, one or more inertial measurement unit (IMU) sensors 666 (e.g., one or more accelerometers, one or more gyroscopes, one or more magnetometers, magnetometers, etc.), one or more microphones 696, one or more stereo cameras 668, one or more wide-angle cameras 670 (e.g., fisheye cameras), one or more infrared cameras 672, one or more surround cameras 674 (e.g., 360-degree cameras), one or more long and / or medium range cameras 698, one or more speed sensors 644 (e.g., to measure a speed of vehicle 600), one or more vibration sensors 642, one or more steering sensors 640, one or more brake sensors (e.g., as part of brake sensor system 646), and / or other sensor types.

[0098] One or more of controllers 636 can receive inputs (e.g., represented by input data) from instrument cluster 632 of vehicle 600 and provide outputs (e.g., represented by output data, display data, etc.) through human-machine interface (HMI) display 634, audio annunciator, speaker, etc., and / or through other components of vehicle 600. The outputs can include information such as vehicle speed, velocity, time, map data (e.g., high-definition (“HD”) map 622 of Figure 6C

[0099] ​The vehicle 600 also includes a network interface 624 that can communicate over one or more networks using one or more wireless antennas 626 and / or modems. For example, the network interface 624 can be capable of communicating over Long Term Evolution (“LTE”), Wideband Code Division Multiple Access (“WCDMA”), Universal Mobile Telecommunications System (“UMTS”), Global System for Mobile Communications (“GSM”), IMT-CDMA Multi-Carrier (“CDMA2000”), and / or the like. The one or more wireless antennas 626 can also enable communication between objects (e.g., vehicles, mobile devices, and / or the like) in the environment using one or more local area networks (e.g., Bluetooth, Bluetooth Low Energy (“LE”), Z-Wave, ZigBee, and / or the like and / or low power wide area networks (LPWANs) such as LoRaWAN, SigFox, and / or the like).

[0100] Figure 6B is an example autonomous vehicle 600 according to some embodiments of the present disclosure Figure 6A Camera positions and fields of view of the example autonomous vehicle 600. The cameras and respective fields of view are one example embodiment and are not intended to be limiting. For example, additional and / or alternative cameras can be included and / or the cameras can be located at different positions on the vehicle 600.

[0101] Camera types for the cameras can include, but are not limited to, digital cameras that can be suitable for components and / or systems of the vehicle 600. One or more of the cameras can operate at Automotive Safety Integrity Level (ASIL) B and / or other ASILs. According to embodiments, the camera types can have any image capture rate, such as 60 frames per second (fps), 120 frames, 240 frames, and / or the like. The cameras can use a rolling shutter, a global shutter, another type of shutter, or a combination thereof. In some examples, a color filter array can include a red clear color clear (RCCC) color filter array, a red clear color blue (RCCB) color filter array, a red blue green clear (RBGC) color filter array, a Foveon X3 color filter array, a Bayer sensor (RGGB) color filter array, a monochrome sensor color filter array, and / or other types of color filter arrays. In some embodiments, a clear pixel camera can be used, such as a camera with a

[0102] In some examples, one or more of the cameras can be used to perform advanced driver assistance system (ADAS) functions (e.g., as part of a redundant or fail-safe design). For example, a multi-function single camera can be installed to provide lane departure warning, traffic sign assist, and intelligent headlamp control, among other functions. One or more of the cameras (e.g., all of the cameras) can record and provide image data (e.g., video) simultaneously.

[0103] The one or more cameras may be mounted in a mounting assembly, such as a custom designed (three-dimensional ("3D") printed) assembly, to cut out stray light and interior vehicle reflections (e.g., reflections of the dashboard off of the windshield mirror) that may interfere with the camera's ability to capture image data. With respect to the wing mirror mounting assembly, the wing mirror assembly may be custom 3D printed so that the camera mounting plate matches the shape of the wing mirror. In some examples, the one or more cameras may be integrated into the wing mirror. For side view cameras, the one or more cameras may also be integrated into the four pillars at each corner of the cabin.

[0104] A camera (e.g., a front-facing camera) having a field of view that includes a portion of the environment in front of the vehicle 600 can be used for a surround view to help identify the forward path and obstacles, as well as to assist in providing information critical to generating an occupancy grid and / or determining a preferred vehicle path with the assistance of one or more controllers 636 and / or a control SOC. The front-facing camera can be used to perform many of the same ADAS functions as lidar, including emergency braking, pedestrian detection, and collision avoidance. The forward-facing camera can also be used for ADAS functions and systems, including lane departure warning ("LDW"), automatic cruise control ("ACC"), and / or other functions, such as traffic sign recognition.

[0105] Various cameras may be used in a front-facing configuration, including, for example, a monocular camera platform including a complementary metal oxide semiconductor ("CMOS") color imager. Another example may be a wide-angle camera 670 that may be used to sense objects entering the field of view from the periphery (e.g., pedestrians, crossing traffic, or bicycles). Although Figure 6B Only one wide-angle camera is shown in FIG, but there may be any number (including zero) of wide-angle cameras 670 on vehicle 600. In addition, any number of long-range cameras 698 (e.g., a long-angle stereo camera pair) can be used for depth-based object detection, particularly for objects for which a neural network has not yet been trained. One or more long-range cameras 698 can also be used for object detection and classification and basic target tracking.

[0106] Any number of stereo cameras 668 can also be included in the front-facing configuration. In at least one embodiment, one or more stereo cameras 668 can include an integrated control unit that includes a scalable processing unit that can provide programmable logic (“FPGA”) and a multi-core microprocessor with integrated controller area network (“CAN”) or Ethernet interfaces on a single chip. This unit can be used to generate a 3D map of the vehicle’s environment, including distance estimates for all points in the image. One or more alternative stereo cameras 668 can include a compact stereo vision sensor that can include two camera lenses (one on the left and one on the right) and an image processing chip that can measure the distance from the vehicle to a target object and use the generated information (e.g., metadata) to activate automatic emergency braking and lane departure warning functions. In addition to the stereo cameras described herein, or alternatively, other types of stereo cameras 668 can be used.

[0107] Cameras with fields of view that include portions of the environment to the sides of the vehicle 600 (e.g., side-view cameras) can be used for surround view, providing information for creating and updating the occupancy grid and generating side collision warnings. For example, one or more surround cameras 674 (e.g., four surround cameras 674 as shown in Figure 6B FIG. 6) can be positioned on the vehicle 600. One or more surround cameras 674 can include one or more wide-view cameras 670, one or more fisheye cameras, one or more 360-degree cameras, etc. For example, four fisheye cameras can be located at the front, back, and sides of the vehicle. In alternative arrangements, the vehicle can use three surround cameras 674 (e.g., left, right, and rear), and can utilize one or more other cameras (e.g., front-facing cameras) as a fourth surround view camera.

[0108] Cameras with fields of view that include portions of the environment to the rear of the vehicle 600 (e.g., rear-view cameras) can be used for parking assistance, surround view, rear-end warnings, and creating and updating the occupancy grid. A variety of cameras can be used, including but not limited to cameras that are also suitable as front-facing cameras (e.g., one or more long- and / or mid-range cameras 698, one or more stereo cameras 668, one or more infrared cameras 672, etc.), as described herein.

[0109] Figure 6C is a vehicle 600 according to some embodiments of the present disclosure Figure 6AFIG. 1 is a block diagram of an example system architecture of an example autonomous vehicle 600. It should be understood that this and other arrangements described herein are set forth only as examples. Other arrangements and elements (e.g., machines, interfaces, functions, orders, groupings of functions, etc.) can be used in addition to or instead of those shown, and some elements can be omitted altogether. Further, many of the elements described herein are functional entities that can be implemented as discrete or distributed components or in conjunction with other components, and in any suitable combination and location of components, can be implemented. Various functions described herein as being performed by entities can be performed in hardware, firmware, and / or software. For instance, various functions can be performed by a processor executing instructions stored in memory.

[0110] Figure 6C Each component, feature, and system of vehicle 600 is connected through bus 602. Bus 602 can include a controller area network (CAN) data interface (which can also be referred to herein as a “CAN bus”). The CAN can be a network within vehicle 600 that is used to help control various features and functions of vehicle 600, such as the driving of brakes, acceleration, braking, steering, windshield wipers, etc. The CAN bus can be configured to have tens or even hundreds of nodes, each with its own unique identifier (e.g., CAN ID). The CAN bus can be read to find steering wheel angle, ground speed, engine revolutions per minute (RPM), button positions, and / or other vehicle status indicators. The CAN bus can comply with ASIL B standards.

[0111] Although bus 602 is described herein as a CAN bus, this is not intended to be limiting. For example, FlexRay and / or Ethernet can be used in addition to or instead of the CAN bus. Further, although bus 602 is represented using a single line, this is not intended to be limiting. For example, there can be any number of buses 602, which can include one or more CAN buses, one or more FlexRay buses, one or more Ethernet buses, and / or one or more other types of buses that use different protocols. In some examples, two or more buses 602 can be used to perform different functions, and / or can be used for redundancy. For example, a first bus 602 can be used for collision avoidance functions, and a second bus 602 can be used for drive control. In any example, each bus 602 can communicate with any component of vehicle 600, and two or more buses 602 can communicate with the same component. In some examples, each SoC 604, each controller 636, and / or each computer within the vehicle can have access to the same input data (e.g., inputs from sensors of vehicle 600), and can be connected to a common bus, such as a CAN bus.

[0112] The vehicle 600 can include one or more controllers 636, as described herein with respect to the controller. The controller 636 can be used for various functions. The one or more controllers 636 can be coupled to any of the various other components and systems of the vehicle 600, and can be used to control the vehicle 600, the artificial intelligence of the vehicle 600, the infotainment of the vehicle 600, etc. Figure 6A

[0113] The vehicle 600 can include one or more system on chips (SoCs) 604. The SoC 604 can include one or more CPUs 606, one or more GPUs 608, one or more processors 610, one or more caches 612, one or more accelerators 614, one or more data stores 616, and / or other components and features not shown. The one or more SoCs 604 can be used to control the vehicle 600 in various platforms and systems. For example, the one or more SoCs 604 can be combined in a system (e.g., a system of the vehicle 600) with an HD map 622 that can obtain map refreshes and / or updates from one or more servers (e.g., servers 678) via a network interface 624. Figure 6D

[0114] The one or more CPUs 606 can include a CPU cluster or CPU complex (or referred to herein as a “CCPLEX”). The one or more CPUs 606 can include multiple cores and / or a level two cache. For example, in some embodiments, the one or more CPUs 606 can include eight cores in a coherent multi-processor configuration. In some embodiments, the one or more CPUs 606 can include four dual-core clusters with each cluster having a dedicated level two cache (e.g., a 2 MB level two cache). The one or more CPUs 606 (e.g., the CCPLEX) can be configured to support simultaneous cluster operation such that any combination of clusters of CPUs 606 are active at any given time.

[0115] ​​The one or more CPUs 606 can implement power management capabilities including one or more of the following: a single hardware block that can be automatically clock-gated when idle to save dynamic power; each core clock can be gated when the core is not actively executing instructions due to execution of WFI / WFE instructions; each core can be independently power-gated; each cluster of cores can be independently clock-gated when all cores are clock-gated or power-gated; and / or each cluster of cores can be independently power-gated when all cores are power-gated. The one or more CPUs 606 can further implement enhanced algorithms for managing power states in which allowed power states and expected wake-up times are specified and the hardware / microcode determines the best power state for the cores, clusters, and CCPLEX to enter. The processing cores can support a simplified power state input sequence in software and offload the work to microcode.

[0116] The one or more GPUs 608 can include an integrated GPU (or “iGPU” as referred to herein). The GPU 608 can be programmable and can be efficient on parallel workloads. In some examples, the one or more GPUs 608 can use an enhanced tensor instruction set. The one or more GPUs 608 can include one or more streaming microprocessors, where each streaming microprocessor can include a level one cache (e.g., a level one cache having at least 96 KB of storage capacity) and two or more streaming microprocessors can share a level two cache (e.g., a level two cache having 512 KB of storage capacity). In some embodiments, the one or more GPUs 608 can include at least eight streaming microprocessors. The one or more GPUs 608 can use one or more computing application programming interfaces (APIs). Further, the one or more GPUs 608 can use one or more parallel computing platforms and / or programming models (e.g., NVIDIA’s CUDA).

[0117] The one or more GPUs 608 can be power optimized for best performance in automotive and embedded use cases. For example, the one or more GPUs 608 can be fabricated on a fin-type field effect transistor (FinFET). However, this is not intended to be limiting, and other semiconductor fabrication processes can be used to fabricate the one or more GPUs 608. Each streaming microprocessor can incorporate multiple mixed-precision processing cores partitioned into multiple blocks. For example, but not by way of limitation, 64 PF32 cores and 32 PF64 cores can be divided into four processing blocks. In such an example, each processing block can be allocated 16 FP32 cores, 8 FP64 cores, 16 INT32 cores, two mixed-precision NVIDIA Tensor Cores for deep learning matrix algorithms, an L0 instruction cache, a warp scheduler, a dispatch unit, and / or a 64 KB register file. Further, the streaming microprocessor can include independent parallel integer and floating point data paths to provide efficient execution of workloads through mixed compute and addressing compute. The streaming microprocessor can include independent thread scheduling capabilities to enable more fine-grained synchronization and cooperation between parallel threads. The streaming microprocessor can include a combined level one data cache and shared memory unit to facilitate both simplified programming and increased performance.

[0118] The one or more GPUs 608 can include a high bandwidth memory (HBM) and / or a 16 GB HBM2 memory subsystem to provide, in some examples, about 900 GB / second peak memory bandwidth. In some examples, in addition to or alternatively from HBM memory, synchronous graphics random access memory (SGRAM) is used, such as fifth generation graphics double data rate synchronous random access memory (GDDR5).

[0119] A fifth generation GPU 608 can include a unified memory technology that includes access counters to allow more accurate migration of memory pages to the processor that accesses them most frequently, thereby improving efficiency of memory ranges shared between processors. In some examples, an address translation service (ATS) support can be used to allow the one or more GPUs 608 to directly access one or more CPU 606 page tables. In such examples, when a one or more GPU 608 memory management unit (MMU) experiences a miss, an address translation request can be sent to the one or more CPUs 606. In response, the one or more CPUs 606 can look up a virtual to physical mapping for the address in their page tables and send the translation back to the one or more GPUs 608. Thus, the unified memory technology can allow a single unified virtual address space for memory of both the one or more CPUs 606 and the one or more GPUs 608, thereby simplifying one or more GPU 608 programming and porting applications to the one or more GPUs 608.

[0120] In addition, one or more GPUs 608 can include an access counter that can track how frequently one or more GPUs 608 access memory of other processors. The access counter can help ensure that memory pages are moved into physical memory of the processor that accesses the page most frequently.

[0121] One or more SoCs 604 can include any number of caches 612, including the caches 612 described herein. For example, one or more caches 612 can include an L3 cache that is available to both one or more CPUs 606 and one or more GPUs 608 (e.g., connected to both one or more CPUs 606 and one or more GPUs 608). The cache 612 can include a write-back cache that can track the state of lines, such as by using a cache coherency protocol (e.g., MEI, MESI, MSI, etc.). Although smaller cache sizes can be used, the L3 cache can include 4MB or more, according to embodiments.

[0122] One or more SoCs 604 can include one or more arithmetic logic units (ALUs) that can be used to perform processing related to various tasks or operations of the vehicle 600, such as processing DNNs. In addition, one or more SoCs 604 can include one or more floating point units (FPUs) or other mathematical co-processors or digital co-processor types for performing mathematical operations within the system. For example, one or more SoCs 604 can include one or more FPUs integrated as execution units within the CPUs 606 and / or GPUs 608.

[0123] One or more SoCs 604 can include one or more accelerators 614 (e.g., hardware accelerators, software accelerators, or a combination thereof). For example, one or more SoCs 604 can include a hardware acceleration cluster that can include optimized hardware accelerators and / or large on-chip memory. The large on-chip memory (e.g., 4MB of SRAM) can enable the hardware acceleration cluster to accelerate neural networks and other computations. The hardware acceleration cluster can be used to supplement one or more GPUs 608 and offload some tasks of one or more GPUs 608 (e.g., freeing up more cycles of one or more GPUs 608 to perform other tasks). For example, one or more accelerators 614 can be used for target workloads (e.g., perception, convolutional neural networks (CNNs), etc.) that are stable enough to be suitable for acceleration. The term “CNN” used herein can include all types of CNNs, including region-based or region convolutional neural networks (RCNNs) and fast RCNNs (e.g., for object detection).

[0124] The one or more accelerators 614 (e.g., hardware acceleration clusters) can include one or more deep learning accelerators (DLAs). The one or more DLAs can include one or more tensor processing units (TPUs) that can be configured to provide an additional 100 trillion operations per second for deep learning applications and inferencing. The TPUs can be accelerators configured to perform and optimized for image processing functions (e.g., for CNNs, RCNNs, etc.). The one or more DLAs can also be optimized for specific neural network types and floating point operations, as well as inferencing. The design of the one or more DLAs can provide higher performance per mm than general purpose GPUs and significantly more than CPUs. The one or more TPUs can perform a number of functions including single instance convolution functions, for example, supporting INT8, INT16, and FP16 data types for features and weights, as well as post-processor functions.

[0125] The one or more DLAs can quickly and efficiently perform neural networks, especially CNNs, on processed or unprocessed data for any of a variety of functions, including but not limited to: CNNs for object recognition and detection using data from camera sensors; CNNs for distance estimation with data from camera sensors; CNNs for emergency vehicle detection and identification and detection using microphone data; CNNs for face recognition and vehicle owner identification using data from camera sensors; and / or CNNs for safety and / or safety related events.

[0126] The one or more DLAs can perform any of the functions of the one or more GPUs 608, for example, a designer can perform any of the functions for the one or more DLAs or the one or more GPUs 608 by using an inferencing accelerator. For example, a designer can concentrate the processing of CNNs and floating point operations on the one or more DLAs and leave other functions to the one or more GPUs 608 and / or the one or more other accelerators 614.

[0127] The one or more accelerators 614 (e.g., hardware acceleration clusters) can include programmable vision accelerators (PVAs), which can also be referred to herein as computer vision accelerators. The one or more PVAs can be designed and configured to accelerate computer vision algorithms for advanced driver assistance systems (ADAS), autonomous driving, and / or augmented reality (AR) and / or virtual reality (VR) applications. The one or more PVAs can provide a balance between performance and flexibility. For example, each PVA can include, for example but not limited to, any number of reduced instruction set computer (RISC) cores, direct memory access (DMA), and / or any number of vector processors.

[0128] The RISC cores can interact with image sensors (e.g., image sensors of any of the cameras described herein), one or more image signal processors, etc. Each RISC core can include any number of memories. The RISC cores can use any of a variety of protocols, depending on the embodiment. In some examples, the RISC cores can execute a real-time operating system (RTOS). The RISC cores can be implemented using one or more integrated circuit devices, application specific integrated circuits (asic), and / or memory devices. For example, the RISC cores can include instruction caches and / or tightly coupled RAM.

[0129] The DMA can enable the PVA assembly to access system memory independently of one or more CPUs 606. The DMA can support any functionality for optimizing the PVA, including but not limited to supporting multi-dimensional addressing and / or circular addressing. In some examples, the DMA can support up to six or more dimensions of addressing, which can include block width, block height, block depth, horizontal block stride, vertical block stride, and / or depth stride.

[0130] The vector processors can be programmable processors that are designed to efficiently and flexibly execute programming of computer vision algorithms, and provide signal processing capabilities. In some examples, the PVA can include a PVA core and two vector processing subsystem partitions. The PVA core can include a processor subsystem, one or more DMA engines (e.g., two DMA engines), and / or other peripherals. The vector processing subsystems can operate as the main processing engines of the PVA, and can include vector processing units (VPUs), instruction caches, and / or vector memories (e.g., VMEMs). The VPU cores can include digital signal processors, such as single instruction, multiple data (SIMD), very long instruction word (VLIW) digital signal processors. The combination of SIMD and VLIW can improve throughput and speed.

[0131] Each vector processor can include an instruction cache, and can be coupled to a dedicated memory. As a result, in some examples, each vector processor can be configured to execute independently of the other vector processors. In other examples, the vector processors included in a particular PVA can be configured to employ data parallelism. For example, in some embodiments, multiple vector processors included in a single PVA can perform the same computer vision algorithm on different regions of an image. In other examples, the vector processors included in a particular PVA can perform different computer vision algorithms on the same image simultaneously, or even different algorithms on sequential images or portions of an image. Any number of PVAs can be included in a hardware acceleration cluster, and any number of vector processors can be included in each PVA, among other things. Furthermore, the PVAs can include additional error-correcting code (ECC) memory to enhance overall system security.

[0132] The one or more accelerators 614 (e.g., hardware acceleration clusters) can include computer vision network on-chip and SRAM for providing high bandwidth, low latency SRAM for the one or more accelerators 614. In some examples, the on-chip memory can include at least 4 MB of SRAM, including but not limited to, eight field-programmable memory blocks accessible by the PVA and the DLA. Each pair of memory blocks can include an advanced peripheral bus (APB) interface, configuration circuitry, a controller, and a multiplexer. Any type of memory can be used. The PVA and the DLA can access memory through a backbone that provides high-speed memory access for the PVA and the DLA. The backbone can include a computer vision network on-chip that interconnects the PVA and the DLA to memory (e.g., using an APB).

[0133] The computer vision network on-chip can include an interface that determines that both the PVA and the DLA provide ready and valid signals before transmitting any control signals / addresses / data. Such an interface can provide independent phases and independent channels for transmitting control signals / addresses / data, as well as burst communications for continuous data transmission. Such an interface can comply with ISO 26262 or IEC 61508 standards, but other standards and protocols can also be used.

[0134] In some examples, the one or more SoCs 604 can include real-time ray tracing hardware accelerators, as described in U.S. Patent Application No. 16 / 101,232, filed August 10, 2018. The real-time ray tracing hardware accelerators can be used to quickly and efficiently determine locations and ranges of objects (e.g., within a world model), generate real-time visualizations simulations, for radar signal interpretation, sound propagation synthesis and / or analysis, sonar system simulation, general wave propagation simulation, comparison with lidar data for localization, and / or other functions and / or other uses. In some embodiments, one or more tree traversal units (ttus) can be used to perform one or more ray tracing related operations.

[0135] The one or more accelerators 614 (e.g., hardware acceleration clusters) have a wide range of uses in the context of autonomous driving. The PVA can be a programmable vision accelerator that can be used in key processing stages for ADAS and autonomous vehicles. The capabilities of the PVA are well suited to the domain of algorithms that need to be processed predictably with low power and low latency. In other words, the PVA performs well on semi-dense or regular dense computations, even on small data sets that need low latency and low power predictable runtimes. Thus, in the context of autonomous vehicle platforms, the PVA is designed to run classic computer vision algorithms because they are very effective at object detection and integer math operations.

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

[0137] In some examples, the PVA can be used to perform dense optical flow. According to processing raw radar data (e.g., using a 4D fast Fourier transform) provides processed radar. In other examples, the PVA is used for time-of-flight depth processing, e.g., by processing raw time-of-flight data to provide processed time-of-flight data.

[0138] The DLA can be used to run any type of network to enhance control and driving safety, e.g., including a neural network that outputs a confidence measure for each object detection. Such a confidence value can be interpreted as a probability, or provide a relative “weight” of each detection relative to other detections. The confidence value enables the system to further decide which detections should be treated as true positive detections and not false positive detections. For example, the system can set a threshold for the confidence and only consider detections that exceed the threshold as true positive detections. In an automatic emergency braking (AEB) system, a false positive detection would cause the vehicle to automatically perform an emergency brake, which is obviously undesirable. Thus, only the most reliable detections should be considered as a trigger for AEB. The DLA can run a neural network to regress a confidence value. The neural network can take as its input at least some subset of parameters, e.g., bounding box dimensions, an obtained estimate of the ground plane (e.g., from another subsystem), inertial measurement unit (IMU) sensor 666 outputs related to the vehicle 600 orientation, distance, a three-dimensional position estimate of the object obtained from the neural network and / or other sensors (e.g., lidar sensor 664 or radar sensor 660), etc.

[0139] The one or more SoCs 604 can include one or more data stores 616 (e.g., memory). The data stores 616 can be on-chip memory of the SoC 604, which can store neural networks to be executed on the GPU and / or DLA. In some examples, the data stores 616 can be large enough to store multiple instances of a neural network for redundancy and safety. The data stores 612 can include a level two or level three cache 612. As described herein, a reference to the one or more data stores 616 can include a reference to memory associated with the PVA, DLA, and / or one or more other accelerators 614.

[0140] The one or more SoCs 604 can include one or more processors 610 (e.g., embedded processors). The processors 610 can include a boot and power management processor that can be a dedicated processor and subsystem for handling boot power and management functions and related security enforcement. The boot and power management processor can be part of the one or more SoCs 604 boot sequence and can provide runtime power management services. The boot power and management processor can provide clock and voltage programming, system low power state transition assistance, management of SoC 604 thermal and temperature sensors, and / or management of SoC 604 power states. Each temperature sensor can be implemented as a ring oscillator that outputs a frequency proportional to temperature, and the one or more SoCs 604 can use the ring oscillator to detect temperature of the one or more CPUs 606, the one or more GPUs 608, and / or the one or more accelerators 614. If the temperature is determined to exceed a threshold, the boot and power management processor can enter a temperature fault routine and place the one or more SoCs 604 in a low power state and / or place the vehicle 600 in a driver safe park mode (e.g., safely park the vehicle 600).

[0141] The one or more processors 610 can also include a set of embedded processors that can be an audio processing engine. The audio processing engine can be an audio subsystem capable of full hardware support for multi-channel audio through a number of interfaces and a wide and flexible set of audio I / O interfaces. In some examples, the audio processing engine is a dedicated processor core of a digital signal processor with dedicated RAM.

[0142] The one or more processors 610 can also include an always-on processor engine that can provide the necessary hardware functionality to support low power sensor management and wake-up use cases. The always-on processor engine can include a processor core, tightly coupled RAM, supporting peripherals (e.g., timers and interrupt controllers), various I / O controller peripherals, and routing logic.

[0143] The one or more processors 610 can also include a safety cluster engine that includes a dedicated processor subsystem for handling safety management for automotive applications. The safety cluster engine can include two or more processor cores, tightly coupled RAM, supporting peripherals (e.g., timers, interrupt controllers, etc.), and / or routing logic. In safety mode, the two or more cores can run in lockstep mode and as a single core with comparison logic to detect any differences between their operations.

[0144] The one or more processors 610 can also include a real-time camera engine that can include a dedicated processor subsystem for handling real-time camera management.

[0145] The one or more processors 610 can also include a high dynamic range signal processor, which can include an image signal processor that is a hardware engine that is part of the camera processing pipeline.

[0146] The one or more processors 610 can include a video image compositor, which can be a processing block (e.g., implemented on a microprocessor) that implements video post-processing functions required by a video playback application to generate the final image for the player window. The video image compositor can perform lens distortion correction on the one or more wide-angle cameras 670, the one or more surround cameras 674, and / or the in-cabin monitoring camera sensors. The in-cabin monitoring camera sensors are preferably monitored by a neural network running on another instance of the advanced SoC that is configured to identify in-cabin events and respond accordingly. The in-cabin system can perform lip reading to activate cellular services and place a phone call, dictate an email, change the vehicle destination, activate or change the vehicle’s infotainment system and settings, or provide voice-activated web surfing. Certain functions can only be available to the driver when the vehicle is operating in an autonomous mode, otherwise they will be disabled.

[0147] The video image compositor can include enhanced temporal noise reduction for spatial and temporal noise reduction. For example, where motion occurs in a video, the noise reduction appropriately weights the spatial information, reducing the weight of information provided by adjacent frames. Where an image or portion of an image does not include motion, the temporal noise reduction performed by the video image compositor can use information from a previous image to reduce noise in the current image.

[0148] The video image compositor can also be configured to perform stereo correction on input stereoscopic lens frames. The video image compositor can also be used for user interface composition when the operating system desktop is in use, and does not require the GPU 608 to continuously render new surfaces. The video image compositor can be used to offload the one or more GPUs 608 to improve performance and responsiveness, even when the one or more GPUs 608 are powered on and active when performing 3D rendering.

[0149] The one or more SoCs 604 can also include a Mobile Industry Processor Interface (MIPI) camera serial interface for receiving video and input from cameras, a high-speed interface, and / or a video input block that can be used for camera and related pixel input functions. The one or more SoCs 604 can also include one or more input / output controllers that can be controlled by software and can be used to receive I / O signals that do not have a specific role assigned.

[0150] The one or more SoCs 604 can also include a wide range of peripheral interfaces to enable communication with peripherals, audio codecs, power management, and / or other devices. The one or more SoCs 604 can be used to process data from cameras (e.g., over a Gigabit Multimedia Serial Link and Ethernet connection), sensors (e.g., one or more lidar sensors 664, one or more radar sensors 660, etc. that can be connected over an Ethernet connection), from the bus 602 (e.g., speed of the vehicle 600, steering wheel position, etc.), from the one or more GNSS sensors 658 (e.g., over an Ethernet or CAN bus connection). The one or more SoCs 604 can also include a dedicated high-performance mass storage controller that can include its own DMA engine and can be used to free the one or more CPUs 606 from routine data management tasks.

[0151] The one or more SoCs 604 can be an end-to-end platform with a flexible architecture spanning automation levels 3-5, providing a comprehensive functional safety architecture that leverages and effectively utilizes computer vision and ADAS technology for diversity and redundancy, providing a platform for flexible and reliable driving software stacks as well as deep learning tools. The one or more SoCs 604 can be faster, more reliable, and even more energy efficient and space saving compared to traditional systems. For example, when the one or more accelerators 614 are combined with the one or more CPUs 606, the one or more GPUs 608, and the one or more data stores 616, a fast, efficient platform can be provided for level 3-5 autonomous vehicles.

[0152] Thus, the technology provides capabilities and functionality that traditional systems cannot achieve. For example, computer vision algorithms can be executed on CPUs, which can be configured using high-level programming languages (e.g., the C programming language) to perform a wide variety of processing algorithms on a wide variety of visual data. However, CPUs often cannot meet the performance requirements of many computer vision applications, such as those related to execution time and power consumption. In particular, many CPUs cannot execute complex object detection algorithms in real time, which is a requirement for on-board ADAS applications and for actual level 3-5 autonomous vehicles.

[0153] In comparison to traditional systems, by providing CPU complexes, GPU complexes, and hardware-accelerated clusters, the technology described herein allows multiple neural networks to be executed simultaneously and / or sequentially, and allows the results to be combined together to enable 3-5 level autonomous driving functionality. For example, a CNN executing on a DLA or dGPU (e.g., one or more GPUs 620) can include text and word recognition, allowing the supercomputer to read and understand traffic signs, including signs for which a neural network has not been specifically trained. The DLA can also include a neural network capable of recognizing, interpreting, and providing a semantic understanding of the sign, and passing that semantic understanding to a path planning module running on a CPU complex.

[0154] Another example is that multiple neural networks can be run simultaneously, as needed for 3, 4, or 5 level driving. For example, a warning sign consisting of the words "Warning: Flashing lights indicate icy conditions" and a light can be interpreted independently or collectively by multiple neural networks. The sign itself can be recognized as a traffic sign by a first deployed neural network (e.g., a trained neural network), the text "Flashing lights indicate icy conditions" can be interpreted by a second deployed neural network, and the flashing light can be recognized by a third deployed neural network operating over multiple frames, informing the vehicle path planning software (preferably executing on a CPU complex) of the presence of flashing lights. All three neural networks can be run simultaneously, for example within a DLA and / or on one or more GPUs 608.

[0155] In some examples, a CNN for face recognition and owner recognition can use data from a camera sensor to identify the presence of an authorized driver and / or owner of the vehicle 600. When the owner approaches the driver's door and opens the car light, the vehicle can be unlocked using a normally open sensor processing engine, and, in a safe mode, disabled when the owner leaves the vehicle. In this way, the one or more SoCs 604 provide anti-theft and / or carjacking protection.

[0156] In another example, a CNN for emergency vehicle detection and identification can use data from the microphones 696 to detect and identify emergency vehicle sirens. Unlike traditional systems that use a general classifier to detect sirens and manually extract features, the one or more SoCs 604 use a CNN to classify the environment and urban sounds, as well as to classify visual data. In a preferred embodiment, the CNN running on the DLA is trained to identify the relative closing speed of an emergency vehicle (e.g., by using the Doppler effect). The CNN can also be trained to identify emergency vehicles specific to the region in which the vehicle is operating, as identified by the one or more GNSS sensors 658. Thus, for example, when operating in Europe, the CNN will seek to detect European sirens, and when in the United States, the CNN will seek to identify only North American sirens. Once an emergency vehicle is detected, a control program can be used to execute an emergency vehicle safety routine with the aid of the ultrasonic sensors 662, causing the vehicle to slow down, pull over, stop, and / or idle until the one or more emergency vehicles pass.

[0157] The vehicle can include one or more CPUs 618 (e.g., one or more discrete CPUs or one or more dCPUs) that can be coupled to the one or more SoCs 604 over a high-speed interconnect (e.g., PCIE). For example, the one or more CPUs 618 can include an X86 processor. The CPU 618 can be used to perform any of a variety of functions, including arbitrating potentially inconsistent results between the ADAS sensors and the SoCs 604, and / or monitoring the status and health of the one or more controllers 636 and / or infotainment SoC 630.

[0158] The vehicle 600 can include one or more GPUs 620 (e.g., one or more discrete GPUs or one or more dGPUs) that can be coupled to the SoCs 604 over a high-speed interconnect (e.g., NVIDIA’s NVLINK). The one or more GPUs 620 can provide additional artificial intelligence functionality, such as by executing redundant and / or different neural networks, and can be used to train and / or update neural networks based on input (e.g., sensor data) from the sensors of the vehicle 600.

[0159] The vehicle 600 can also include a network interface 624, which can include one or more wireless antennas 626 (e.g., one or more wireless antennas for different communication protocols, such as cellular antennas, Bluetooth antennas, etc.). The network interface 624 can be used to enable wireless connectivity with the cloud (e.g., with one or more servers 678 and / or other network devices), with other vehicles, and / or with computing devices (e.g., a client device of a passenger) over the Internet. To communicate with other vehicles, a direct link can be established between two vehicles and / or an indirect link can be established (e.g., through a network and the Internet). The direct link can be provided using a vehicle-to-vehicle communication link. The vehicle-to-vehicle communication link can provide the vehicle 600 with information about vehicles in the vicinity of the vehicle 600 (e.g., vehicles in front of, to the side of, and / or behind the vehicle 600). This functionality can be part of a cooperative adaptive cruise control functionality of the vehicle 600.

[0160] The network interface 624 can include a SoC that provides modulation and demodulation functionality and enables the one or more controllers 636 to communicate over wireless networks. The network interface 624 can include a radio frequency front end for up-conversion from baseband to radio frequency and down-conversion from radio frequency to baseband. The frequency conversion can be performed through well-known processes and / or can be performed using a superheterodyne process. In some examples, the radio frequency front end functionality can be provided by a separate chip. The network interface can include wireless functionality for communicating over LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN, and / or other wireless protocols.

[0161] The vehicle 600 can further include one or more data stores 628, which can be off-chip (e.g., off-SoC). The data stores 628 can include one or more storage elements, including RAM, SRAM, DRAM, VRAM, flash memory, hard disks, and / or other components and / or devices that can store at least one bit of data.

[0162] The vehicle 600 can also include one or more GNSS sensors 658. The one or more GNSS sensors 658 (e.g., GPS, assisted GPS sensors, differential GPS (DGPS) sensors, etc.) are used to assist in mapping, perception, occupancy grid generation, and / or path planning functionality. Any number of GNSS sensors 658 can be used, including, for example, but not limited to, using a GPS with a USB connector with an Ethernet-to-serial (RS-232) bridge.

[0163] The vehicle 600 can also include one or more radar sensors 660. The vehicle 600 can use the one or more radar sensors 660 for long-range vehicle detection, even in darkness and / or adverse weather conditions. The radar functional safety level can be ASIL B. The one or more radar sensors 660 can use CAN and / or the bus 602 (e.g., to transmit data generated by the one or more radar sensors 660) for control and access to target tracking data, and in some examples, access to raw data via Ethernet. A variety of radar sensor types can be used. For example, but not by way of limitation, the one or more radar sensors 660 can be suitable for front, rear, and side radar use. In some examples, pulsed Doppler radar sensors are used.

[0164] The one or more radar sensors 660 can include different configurations, such as long-range with narrow field of view, short-range with wide field of view, short-range side coverage, etc. In some examples, long-range radar can be used for adaptive cruise control functionality. Long-range radar systems can provide a wide field of view, for example, up to 250 meters, achieved through two or more independent scans. The one or more radar sensors 660 can help distinguish between static and moving objects, and can be used by the ADAS system for emergency brake assist and forward collision warning. Long-range radar sensors can include a single-base multi-mode radar with multiple (e.g., six or more) fixed radar antennas and high-speed CAN and FlexRay interfaces. In examples with six antennas, the central four antennas can create focused beam patterns designed to record 600 of the environment around the vehicle at higher speeds with minimal traffic interference from adjacent lanes. The other two antennas can expand the field of view, enabling them to quickly detect vehicles entering or leaving the vehicle 600’s lane.

[0165] For example, a mid-range radar system can include a range of up to 660 meters (front) or 80 meters (rear), and a field of view of up to 42 degrees (front) or 650 degrees (rear). A short-range radar system can include, but is not limited to, radar sensors designed to be mounted at both ends of the rear bumper. When mounted at both ends of the rear bumper, such radar sensor systems can produce two beams of light that continuously monitor the blind spots behind and alongside the vehicle.

[0166] A short-range radar system can be used in the ADAS system for blind spot detection and / or lane change assist.

[0167] The vehicle 600 can also include one or more ultrasonic sensors 662. The one or more ultrasonic sensors 662 can be located at the front, rear, and / or sides of the vehicle 600, can be used for parking assistance and / or to create and update the occupancy grid. A variety of ultrasonic sensors 662 can be used, with different ultrasonic sensors 662 used for different detection ranges (e.g., 2.5m, 4m). The one or more ultrasonic sensors 662 can operate at an ASIL B level of functional safety.

[0168] The vehicle 600 can include one or more lidar sensors 664. The one or more lidar sensors 664 can be used for object and pedestrian detection, emergency braking, collision avoidance, and / or other functions. The functional safety rating of the one or more lidar sensors 664 can be ASIL B. In some examples, the vehicle 600 can include multiple lidar sensors 664 (e.g., two, four, six, etc.) that can use Ethernet (e.g., to provide data to a Gigabit Ethernet switch).

[0169] In some examples, the one or more lidar sensors 664 can be capable of providing a list of objects and their distances in a 360-degree field of view. The advertised range of one or more commercial lidar sensors 664 can be approximately 600m, with an accuracy of 2cm-3cm, and support, for example, 600Mbps Ethernet connections. In some examples, one or more flush lidar sensors 664 can be used. In examples of this sort, the one or more lidar sensors 664 can be implemented as small devices that can be embedded in the front, rear, sides, and / or corners of the vehicle 600. In examples of this sort, the one or more lidar sensors 664 can provide up to 120 degrees of horizontal and 35 degrees of vertical field of view, with a range of 200m even for low reflectivity objects. A front-mounted one or more lidar sensors 664 can be configured for a horizontal field of view between 45 degrees and 135 degrees.

[0170] In some examples, lidar technology can also be used, such as 3D flash lidar. 3D flash lidar uses a laser flash as a transmission source, illuminating approximately 200 meters around the vehicle. The flash lidar device includes a receiver that records the laser pulse transmission time and reflected light on each pixel, which in turn corresponds to a range from the vehicle to an object. Flash lidar can generate a high-accuracy, distortion-free environmental image with each laser flash. In some examples, four flash lidar sensors can be deployed, one on each side of the vehicle 600. Available 3D flash lidar systems include solid-state 3D staring array lidar cameras with no moving parts other than a fan (e.g., non-scanning lidar devices). The flash lidar device can use 5 nanosecond Class I (eye-safe) laser pulses per frame and can capture reflected laser light in the form of 3D range point clouds and co-registered intensity data. By using flash lidar, and because flash lidar is a solid-state device with no moving parts, the one or more lidar sensors 664 can be less susceptible to motion blur, vibration, and / or shock.

[0171] The vehicle can also include one or more IMU sensors 666. In some examples, the one or more IMU sensors 666 can be located at the center of the rear axle of the vehicle 600. The one or more IMU sensors 666 can include, for example and without limitation, one or more accelerometers, one or more magnetometers, one or more gyroscopes, one or more magnetic compasses, and / or other sensor types. In some examples, such as in six-axis applications, the one or more IMU sensors 666 can include accelerometers and gyroscopes, while in nine-axis applications, the one or more IMU sensors 666 can include accelerometers, gyroscopes, and magnetometers.

[0172] In some embodiments, the one or more IMU sensors 666 can be implemented as a micro, high-performance GPS-aided inertial navigation system (GPS / INS) that combines micro-electromechanical systems (MEMS) inertial sensors, high-sensitivity GPS receivers, and advanced Kalman filtering algorithms to provide estimates of position, velocity, and attitude. Thus, in some examples, the one or more IMU sensors 666 can enable the vehicle 600 to estimate heading by directly observing and correlating changes in velocity from the GPS to the one or more IMU sensors 666 without input from magnetic sensors. In some examples, the one or more IMU sensors 666 and the one or more GNSS sensors 658 can be combined in a single integrated unit.

[0173] The vehicle can include one or more microphones 696 placed within and / or around the vehicle 600. The one or more microphones 696 can be used for emergency vehicle detection and identification, among others.

[0174] The vehicle can also include any number of camera types, including one or more stereo cameras 668, one or more wide-view cameras 670, one or more infrared cameras 672, one or more surround-view cameras 674, one or more long-range and / or mid-range cameras 698, and / or other camera types. The cameras can be used to capture image data of the entire periphery of the vehicle 600. The types of cameras used depend on the embodiment and requirements of the vehicle 600, and any combination of camera types can be used to provide the necessary coverage around the vehicle 600. Further, the number of cameras can vary depending on the embodiment. For example, the vehicle can include six cameras, seven cameras, ten cameras, twelve cameras, and / or other numbers of cameras. As an example, the cameras can support, but are not limited to, Gigabit Multimedia Serial Link (GMSL) and / or Gigabit Ethernet. Reference will be made herein to Figure 6A and Figure 6B Each camera is described in more detail.

[0175] The vehicle 600 can also include one or more vibration sensors 642. The one or more vibration sensors 642 can measure vibrations of vehicle components, such as axles. For example, changes in vibration can indicate changes in the road surface. In another example, when two or more vibration sensors 642 are used, differences between the vibrations can be used to determine the friction or slip of the road surface (e.g., when the vibration difference is between a power driven axle and a free spinning axle).

[0176] The vehicle 600 can include an ADAS system 638. In some examples, the ADAS system 638 can include a SoC. The ADAS system 638 can include automatic / adaptive / autonomous cruise control (ACC), cooperative adaptive cruise control (CACC), forward collision warning (FCW), automatic emergency braking (AEB), lane departure warning (LDW), lane keep assist (LKA), blind spot warning (BSW), rear cross-traffic warning (RCTW), collision warning system (CWS), lane centering (LC), and / or other features and functionality.

[0177] The ACC system can use one or more radar sensors 660, one or more lidar sensors 664, and / or one or more cameras. The ACC system can include longitudinal ACC and / or lateral ACC. Longitudinal ACC monitors and controls the distance to the vehicle directly in front of the vehicle 600 and automatically adjusts the vehicle speed to maintain a safe distance from the vehicle in front. Lateral ACC performs distance keeping and suggests lane changes for the vehicle 600 when necessary. Lateral ACC is related to other ADAS applications, such as LCA and CWS.

[0178] CACC uses information from other vehicles, which can be received from other vehicles directly through a wireless link, or indirectly through a network connection (e.g., over the Internet) through the network interface 624 and / or one or more wireless antennas 626. The direct link can be provided by a vehicle-to-vehicle (V2V) communication link, while the indirect link can be an infrastructure-to-vehicle (I2V) communication link. Generally, the V2V communication concept provides information about the vehicle in front (e.g., a vehicle 600 that is directly in front of and in the same lane as the vehicle 600), while the I2V communication concept provides information about traffic ahead. A CACC system can include one or both of the I2V and V2V information sources. CACC can be more reliable given the vehicle information ahead of the vehicle 600, and has the potential to improve the smoothness of traffic flow and reduce congestion on the road.

[0179] FCW systems are designed to alert the driver of a hazard so that the driver can take corrective action. FCW systems use a forward-facing camera and / or one or more radar sensors 660 coupled to a dedicated processor, DSP, FPGA, and / or ASIC that is electrically coupled to driver feedback such as a display, speaker, and / or vibration assembly. FCW systems can provide warnings such as a sound, visual warning, vibration, and / or a quick brake pulse.

[0180] AEB systems detect an impending forward collision with another vehicle or other object and can automatically apply the brakes if the driver does not take corrective action within prescribed time or distance parameters. AEB systems can use one or more front-facing cameras and / or one or more radar sensors 660 coupled to a dedicated processor, DSP, FPGA, and / or ASIC. When the AEB system detects a hazard, the driver is typically first alerted to take corrective action to avoid a collision, and if the driver does not take corrective action, the AEB system can automatically apply the brakes to prevent or at least mitigate the effects of the projected collision. AEB systems can include technologies such as dynamic brake support and / or crash imminent braking.

[0181] LDW systems provide visual, audible, and / or tactile warnings such as steering wheel or seat vibration to alert the driver when the vehicle 600 crosses lane markings. The LDW system does not activate when the driver indicates an intentional lane departure by activating a turn signal. LDW systems can use front-side facing cameras coupled to a dedicated processor, DSP, FPGA, and / or ASIC that is electrically coupled to driver feedback such as a display, speaker, and / or vibration assembly.

[0182] An LKA system is a variant of the LDW system. If the vehicle 600 begins to exit the lane, the LKA system provides steering input or braking to correct the vehicle 600.

[0183] A BSW system detects and warns the driver of a vehicle of vehicles within the blind spot of the car. The BSW system can provide visual, audible, and / or tactile alerts to indicate that merging or lane changing is unsafe. The system can provide additional warnings when the driver uses a turn signal. The BSW system can use rear side-facing cameras and / or radar sensors 660 coupled to a dedicated processor, DSP, FPGA, and / or ASIC that is electrically coupled to driver feedback such as a display, speaker, and / or vibration assembly.

[0184] An RCTW system can provide visual, audible, and / or tactile notifications when an object outside the range of the rear camera is detected when the vehicle 600 is backing up. Some RCTW systems include AEB to ensure that vehicle brakes are applied to avoid a collision. The RCTW system can use one or more rear-facing radar sensors 660 coupled to a dedicated processor, DSP, FPGA, and / or ASIC that is electrically coupled to driver feedback such as a display, speaker, and / or vibration assembly.

[0185] Traditional ADAS systems can be prone to false positive results, which can be annoying and distracting to the driver, but typically do not result in catastrophic consequences because the ADAS system alerts the driver and allows the driver to decide whether a safety condition is indeed present and take appropriate action. However, in an autonomous vehicle 600, in the event of a result conflict, the vehicle 600 itself must decide whether to listen to the results from the primary computer or the secondary computer (e.g., the first controller 636 or the second controller 636). For example, in some embodiments, the ADAS system 638 can be a backup and / or secondary computer for providing perception information to a backup computer module. The backup computer plausibility monitor can run redundant different software on hardware components to detect faults in perception and dynamic driving tasks. The output from the ADAS system 638 can be provided to a supervisory MCU. If the outputs of the primary and secondary computers conflict, the supervisory MCU must determine how to reconcile the conflict to ensure safe operation.

[0186] In some examples, the host computer can be configured to provide a confidence score to the monitoring MCU indicating the host computer’s confidence in the selected result. If the confidence score exceeds a threshold, the monitoring MCU can follow the host computer’s direction, regardless of whether the secondary computer provides conflicting or inconsistent results. If the confidence score does not meet the threshold, and the host computer and secondary computer indicate different results (e.g., a conflict), the monitoring MCU can arbitrate between the computers to determine the appropriate result.

[0187] The monitoring MCU can be configured to run one or more neural networks trained and configured to determine conditions under which the secondary computer provides false alarms from the outputs of the host computer and the secondary computer. Thus, the one or more neural networks in the monitoring MCU can learn when the output of the secondary computer is trustworthy and when it is not. For example, when the secondary computer is a radar-based FCW system, the one or more neural networks in the monitoring MCU can learn when the FCW system identifies a metallic object that is not in fact dangerous, such as a drain grate or manhole cover that triggers an alert. Similarly, when the secondary computer is a camera-based LDW system, the neural network in the monitoring MCU can learn to override the LDW when a bicycle or pedestrian is present and lane departure is in fact the safest maneuver. In embodiments that include one or more neural networks running on the monitoring MCU, the monitoring MCU can include at least one of a DLA or GPU adapted to run the one or more neural networks with associated memory. In preferred embodiments, the monitoring MCU can include and / or be comprised as a component of the SoC 604.

[0188] In other examples, the ADAS system 638 can include a secondary computer that performs ADAS functions using traditional computer vision rules. Thus, the secondary computer can use classic computer vision rules (if-then), and the presence of one or more neural networks in the monitoring MCU can improve reliability, safety, and performance. For example, the diversification of implementation and intentional non-identification make the overall system more fault-tolerant, particularly to faults caused by software (or software-hardware interface) functionality. For example, if there is a software defect or bug in the software running on the host computer, and the same overall result is provided by non-identical software code running on the secondary computer, the monitoring MCU can have greater confidence in the correctness of the overall result, that the software or hardware defect on the host computer did not cause a significant error.

[0189] In some examples, the output of the ADAS system 638 can feed into a perception block of the host computer and / or a dynamic driving task block of the host computer. For example, if the ADAS system 638 indicates a forward collision warning due to an object directly in front, the perception block can use this information in identifying the object. In other examples, as described herein, the secondary computer can have its own trained neural network, reducing the risk of false positives.

[0190] The vehicle 600 can also include an infotainment SoC 630 (e.g., an in-vehicle infotainment system (IVI)). Although illustrated and described as a SoC, the infotainment system can not be a SoC and can include two or more discrete components. The infotainment SoC 630 can include a combination of hardware and software that can be used to provide audio (e.g., music, personal digital assistant, navigation instructions, news, radio, etc.), video (e.g., television, movies, streaming media, etc.), telephony (e.g., hands-free calling), network connectivity (e.g., LTE, Wi-Fi, etc.), and / or provide information services to the vehicle 600 (e.g., navigation system, rear park assist, radio data system, vehicle related information such as fuel level, total distance traveled, brake fluid level, oil level, doors open / close, air filter information, etc.). For example, the infotainment SoC 630 can be a radio, disc player, navigation system, video player, USB and Bluetooth connectivity, in-car computer, in-car entertainment, Wi-Fi, steering wheel audio controls, hands-free voice controls, heads-up display (HUD), HMI display 634, telematics, control panel (e.g., for controlling and / or interacting with various components, features, and / or systems), and / or other components. The infotainment SoC 630 can also be used to provide information (e.g., visually and / or audibly) to a user of the vehicle, such as information from the ADAS system 638, autonomous driving information such as planned vehicle maneuvers, trajectory, surrounding environment information (e.g., intersection information, vehicle information, road information, etc.), and / or other information.

[0191] The infotainment SoC 630 can include GPU functionality. The infotainment SoC 630 can communicate with other devices, systems, and / or components of the vehicle 600 over the bus 602 (e.g., CAN bus, Ethernet, etc.). In some examples, the infotainment SoC 630 can be coupled to a supervisory MCU such that the GPU of the infotainment system can perform some self-driving functions in the event of a failure of one or more host controllers 636 (e.g., the host computer and / or the backup computer of the vehicle 600). In such examples, the infotainment SoC 630 can place the vehicle 600 into a driver-to-safe-parking mode, as described herein.

[0192] The vehicle 600 can also include an instrument cluster 632 (e.g., a digital dashboard, an electronic instrument cluster, a digital instrument cluster, etc.). The instrument cluster 632 can include a controller and / or supercomputer (e.g., a discrete controller or supercomputer). The instrument cluster 632 can include a set of instruments such as a speedometer, a fuel level, an oil pressure, a tachometer, an odometer, a turn indicator, a shift position indicator, one or more seatbelt warning lights, one or more park brake warning lights, one or more engine malfunction lights, a supplemental restraint system (SRS) system information, lighting controls, safety system controls, navigation information, etc. In some examples, information can be displayed and / or shared between the infotainment SoC 630 and the instrument cluster 632. In other words, the instrument cluster 632 can be included as part of the infotainment SoC 630, and vice versa.

[0193] Figure 6D one or more cloud-based servers in communication with an example autonomous vehicle 600 according to some embodiments of the present disclosure. Figure 6A A system diagram of a system 676 in communication between an example autonomous vehicle 600. The system 676 can include one or more servers 678, one or more networks 690, and vehicles, including the vehicle 600. The one or more servers 678 can include a plurality of GPUs 684(a)-684(H) (collectively, GPUs 684), PCIe switches 682(a)-682(H) (collectively, PCIe switches 682), and / or CPUs 680(A)-680(B) (collectively, CPUs 680) herein. The GPUs 684, CPUs 680, and PCIe switches can be interconnected by high-speed interconnects, such as, but not limited to, NVLink interfaces 688 developed by NVIDIA and / or PCIE connections 686. In some examples, the GPUs 684 are connected by NVLink and / or NVSwitch SoC, and the GPUs 684 and PCIe switches 682 are connected by PCIe interconnects. Although eight GPUs 684, two CPUs 680, and two PCIe switches are illustrated, this is not intended to be limiting. According to embodiments, each of the one or more servers 678 can include any number of GPUs 684, CPUs 680, and / or PCIe switches. For example, the one or more servers 678 can each include eight, sixteen, thirty-two, and / or more GPUs 684.

[0194] The one or more servers 678 can receive, from a vehicle over the one or more networks 690, image data representative of an image showing an unexpected or changing road condition, such as a road work that recently started. The one or more servers 678 can transmit, to the vehicle over the one or more networks 690, a neural network 692, an updated neural network 692, and / or map information 694, including information about traffic and road conditions. The updates to the map information 694 can include updates to the HD map 622, such as information about construction sites, potholes, detours, flooding, and / or other obstacles. In some examples, the neural network 692, the updated neural network 692, and / or the map information 694 can be sourced from new training and / or experience represented in data received from any number of vehicles in the environment, and / or based on training performed at a data center (e.g., using the one or more servers 678 and / or other servers).

[0195] The one or more servers 678 can be used to train machine learning models (e.g., neural networks) based on training data. The training data can be generated by vehicles, and / or can be generated in simulations (e.g., using game engines). In some examples, the training data is labeled (e.g., the neural network benefits from supervised learning) and / or undergoes other pre-processing, while in other examples, the training data is not labeled and / or pre-processed (e.g., the neural network does not require supervised learning). The training can be performed according to any class or classes of machine learning techniques, including but not limited to: supervised training, semi-supervised training, unsupervised training, self-learning, reinforcement learning, federated learning, transfer learning, feature learning (including principal component and cluster analysis), multilinear subspace learning, manifold learning, representation learning (including spare dictionary learning), rule-based machine learning, anomaly detection, and any variants or combinations. Once the machine learning model is trained, the machine learning model can be used by vehicles (e.g., transmitted to vehicles 690 over the one or more networks, and / or the machine learning model can be used by the one or more servers 678 for remote monitoring of vehicles).

[0196] In some examples, the one or more servers 678 can receive data from vehicles and apply the data to a latest real-time neural network for real-time intelligent inference. The one or more servers 678 can include deep learning supercomputers and / or specialized AI computers powered by GPUs 684, such as the DGX and DGX Station machines developed by NVIDIA. However, in some examples, the one or more servers 678 can include deep learning infrastructure of a data center powered by CPUs only.

[0197] The deep learning infrastructure of the one or more servers 678 can infer quickly in real-time and can use this capability to assess and certify the health of the processors, software, and / or associated hardware in the vehicle 600. For example, the deep learning infrastructure can receive periodic updates from the vehicle 600, e.g., a sequence of images and / or objects that the vehicle 600 locates in the image sequence (e.g., through computer vision and / or other machine learning object classification techniques). The deep learning infrastructure can run its own neural network to identify the objects and compare them to the objects identified by the vehicle 600, and if the results do not match and the infrastructure concludes that the AI in the vehicle 600 is malfunctioning, the one or more servers 678 can send a signal to the vehicle 600 instructing the fail-safe computer of the vehicle 600 to assume control, notify the passengers, and complete a safe parking operation.

[0198] For inference, the one or more servers 678 can include one or more GPUs 684 and one or more programmable inference accelerators (e.g., NVIDIA’s TensorRT). The combination of GPU-powered servers and inference acceleration can make real-time responses possible. In other examples, e.g., where performance is less critical, servers powered by CPUs, FPGAs, and other processors can be used for inference.

[0199] Figure 7A is a block diagram of an example generative language model system 700 suitable for implementing at least some embodiments of the present disclosure. In Figure 7A In the example shown, the generative language model system 700 includes a retrieval-augmented generation (RAG) component 792, an input processor 705, a tokenizer 710, an embedding component 720, a plug-in / API 795, and a generative language model (LM) 730 (which can include an LLM, a VLM, a multi-modal LM, etc.).

[0200] At a high level, input processor 705 can receive input 701 that includes text and / or other types of input data (e.g., audio data, video data, image data, sensor data (e.g., LiDAR, RADAR, ultrasound, etc.), 3D design data, CAD data, Universal Scene Description (USD) data (e.g., OpenUSD, etc.), depending on the architecture of generative LM 730 (e.g., LLM / VLM / MMLM / etc.). In some embodiments, input 701 includes plain text in the form of one or more sentences, paragraphs, and / or documents. Additionally or alternatively, input 701 can include numerical sequences, pre-computed embeddings (e.g., word or sentence embeddings), and / or structured data (e.g., table format, JSON, or XML). In some implementations where generative LM 730 is capable of processing multi-modal input, input 701 can combine text (or can omit text) with image data, audio data, video data, design data, USD data, and / or other types of input data such as, but not limited to, the data described herein. Taking the example of raw input text, input processor 705 can prepare the raw input text in various ways. For example, input processor 705 can perform various types of text filtering to remove noise (e.g., special characters, punctuation, HTML tags, stop words, portions of images, portions of audio, etc.) from the relevant textual content. In examples involving stop words (commonly used words that tend to carry little semantic meaning), input processor 705 can remove stop words to reduce noise and focus the attention of generative LM 730 on more meaningful content. Input processor 705 can apply text normalization, e.g., by converting all characters to lowercase, removing diacritics, and / or handling special cases (such as abbreviations or contractions) to ensure consistency. These are just a few examples, and other types of input processing can be applied.

[0201] In some embodiments, RAG component 792 (which can include one or more RAG models, and / or can use generative LM 730 itself to perform) can be used to retrieve additional information to be used as part of input 701 or a prompt. The RAG can be used to augment the input to the LLM / VLM / MMLM / etc. with external knowledge in order to make the answer to a particular question or query or request more relevant, e.g., in cases where specific knowledge is needed. RAG component 792 can obtain this additional information (e.g., underlying information such as underlying text / image / video / audio / USD / CAD / etc.) from one or more external sources, which can then be fed to the LLM / VLM / MMLM / etc. along with the prompt to improve the accuracy of the model’s response or output.

[0202] For example, in some embodiments, input 701 can be generated using inputs (e.g., questions, requests, etc.) of a query or model in addition to data retrieved using RAG component 792. In some embodiments, input processor 705 can analyze input 701 and communicate with RAG component 792 (or in embodiments, RAG component 792 can be part of input processor 705) in order to identify relevant text and / or other data to provide to generative LM 730 as additional context or source of information from which responses, answers, or outputs 790 are typically identified. For example, where input indicates that a user is interested in the required tire pressure for a particular make and model of vehicle, RAG component 792 can use a RAG model (which performs vector searches in an embedding space, for example) to retrieve tire pressure information or text corresponding thereto from a digital (embedded) version of the user manual for that particular vehicle make and model. Similarly, where a user revisits a chatbot related to a particular product offering or service, RAG component 792 can retrieve a previously stored dialogue history (or at least an abridged version thereof) and include the previous dialogue history with the current inquiry / request as part of input 701 to generative LM 730.

[0203] RAG component 792 can use various RAG techniques. For example, a naive RAG can be used in which documents are indexed, chunked, and applied to an embedding model to generate embeddings corresponding to the chunks. A user query can also be applied to the embedding model and / or another embedding model of RAG component 792, and the embeddings of the chunks as well as the query can be compared to identify the most similar / most relevant embeddings to the query, which can be provided to generative LM 730 to generate an output.

[0204] In some embodiments, more advanced RAG techniques can be used. For example, chunks can undergo a pre-retrieval process (e.g., routing, rewriting, metadata analysis, expansion, etc.) before being passed to an embedding model. Further, outputs of an embedding model can be subjected to a post-retrieval process (e.g., re-ranking, prompt compression, etc.) before the final embeddings are used as a comparison to an input query.

[0205] As a further example, modular RAG techniques can be used, such as techniques similar to naive and / or advanced RAGs but also including features such as hybrid search, recursive retrieval and query engine, StepBack method, subqueries, and hypothetical document embeddings.

[0206] As another example, a Graph RAG can use a knowledge graph as a source of contextual or factual information. The Graph RAG can be implemented using a graph database as a source of contextual information sent to the LLM / VLM / MMLM / etc. Rather than (or in addition to) providing the model with data blocks extracted from larger documents (which can result in a lack of context, factual accuracy, language accuracy, etc.), the Graph RAG can also provide structured entity information to the LLM / VLM / MMLM / etc. by combining structured entity text descriptions with their many attributes and relationships, allowing the model to gain deeper insights. In implementing a Graph RAG, the systems and methods described herein use a graph as a content store and extract relevant document blocks and ask the LLM / VLM / MMLM / etc. to use them to answer. In such embodiments, the knowledge graph can contain relevant textual content and metadata about the knowledge graph, and can also be integrated with a vector database. In some embodiments, the Graph RAG can use the graph as a subject matter expert, where descriptions of concepts and entities relevant to the query / prompt can be extracted and passed to the model as semantic context. These descriptions can include relationships between concepts. In other examples, the graph can be used as a database, where a portion of the query / prompt can be mapped to a graph query, the graph query can be executed, and the LLM / VLM / MMLM / etc. can summarize the results. In such examples, the graph can store relevant factual information, and can use queries (natural language queries) to a graph query tool (NL-to-Graph-query tool) and entity linking. In some embodiments, the Graph RAG (e.g., using a graph database) can be combined with standard (e.g., vector database) RAGs and / or other RAG types to benefit from multiple approaches.

[0207] In any embodiment, the RAG component 792 can implement plugins, APIs, user interfaces, and / or other functionality to perform RAGs. For example, the LLM / VLM / MMLM / etc. can use a Graph RAG plugin to run queries on a knowledge graph to extract relevant information to feed to the model, and can use a standard or vector RAG plugin to run queries on a vector database. For example, the graph database can interact with the REST interface of the plugin such that the graph database is decoupled from the vector database and / or embedding model.

[0208] The tokenizer 710 can segment (e.g., processed) textual data into smaller units (tokens) for subsequent analysis and processing. Depending on the implementation, a token can represent an individual word, subword, character, portion of audio / video / image / etc. Word-based tokenization divides text into individual words, treating each word as a separate token. Subword tokenization breaks down words into smaller meaningful units (e.g., prefixes, suffixes, stems), enabling the generative LM 730 to understand morphological variations and more effectively handle out-of-vocabulary words. Character-based tokenization represents each character as a separate token, enabling the generative LM 730 to process text at a fine-grained level. The choice of tokenization strategy can depend on factors such as the language being processed, the task at hand, and / or characteristics of the training dataset. Accordingly, the tokenizer 710 can convert (e.g., processed) text into a structured format according to a tokenization scheme implemented in a particular embodiment.

[0209] The embedding component 720 can transform discrete tokens into a (e.g., dense, continuous vector) representation of semantic meaning using any known embedding technique. For example, the embedding component 720 can use pre-trained word embeddings (e.g., Word2Vec, GloVe, or FastText), one-hot encoding, term frequency-inverse document frequency (TF-IDF) encoding, one or more embedding layers of a neural network, and / or others.

[0210] In some embodiments where input 701 includes image data / video data / etc., input processor 701 can resize data to a standard size compatible with the format of the corresponding input channel and / or can normalize pixel values to a common range (e.g., 0 to 1) to ensure consistent representation, and embedding component 720 can encode image data using any known technique (e.g., using one or more convolutional neural networks (CNNs) to extract visual features). In some embodiments where input 701 includes audio data, input processor 701 can resample audio files to a consistent sampling rate for uniform processing, and embedding component 720 can extract and encode audio features using any known technique - e.g., in the form of a spectrogram (e.g., a mel-spectrogram). In some embodiments where input 701 includes video data, input processor 701 can extract frames or apply resizing to extracted frames, and embedding component 720 can extract features such as optical flow embeddings or video embeddings and / or can encode temporal information or sequences of frames. In some embodiments where input 701 includes multi-modal data, embedding component 720 can fuse representations of different types of data (e.g., text, image, audio, USD, video, design, etc.) using techniques such as early fusion (concatenation), late fusion (sequential processing), attention-based fusion (e.g., self-attention, cross-attention), etc.

[0211] The generative LM 730 and / or other components of the generative LM system 700 can use different types of neural network architectures depending on the embodiment. For example, a transformer-based architecture (such as used in GPT and the like models) can be implemented, and the transformer-based architecture can include a self-attention mechanism that weights the importance of different words or tokens in an input sequence and / or a feed-forward network that processes the output of the self-attention layer, applies a non-linear transformation to the input representation, and extracts higher-level features. Some non-limiting example architectures include transformers (e.g., encoder-decoder, decoder-only, multi-modal), RNNs, LSTMs, fusion models, diffusion models, cross-modal embedding models that learn a joint embedding space, graph neural networks (GNNs), hybrid architectures that combine different types of architectures for joint distribution learning (such as generative adversarial networks or GANs or adversarial autoencoders (AAEs)), etc. Thus, depending on the embodiment and architecture, the embedding component 720 can apply the encoded representation of the input 701 to the generative LM 730, and the generative LM 730 can process the encoded representation of the input 701 to generate the output 790 (which can include response text and / or other types of data).

[0212] As described herein, in some embodiments, generative LM 730 can be configured to access or use (or be able to access or use) plugins / APIs 795 (which can include one or more plugins, application programming interfaces (APIs), databases, data stores, repositories, etc.). For example, for certain tasks or operations that are not well suited for generative LM 730, the model can have instructions (e.g., as a result of training, and / or based on instructions in a given prompt, such as instructions retrieved using RAG component 792) for accessing one or more plugins / APIs 795 (e.g., third-party plugins) to assist in processing the current input. In such examples, where at least a portion of the prompt is related to restaurants or weather, the model can access one or more restaurant or weather plugins (e.g., via one or more APIs), send at least a portion of the prompt related to the particular plugin / API 795 to that plugin / API 795, the plugin / API 795 can process that information and return an answer to generative LM 730, which can use that response to generate output 790. This process can repeat (e.g., recursively) any number of iterations and use any number of plugins / APIs 795 until output 790 can be generated that addresses each query / question / request / process / operation / etc. from input 701. Thus, the model can rely not only on its own knowledge gained through training on large datasets and / or data retrieved using RAG component 792, but also on the specialized knowledge or optimized nature of one or more external resources (e.g., plugins / APIs 795).

[0213] Figure 7B is a block diagram of an example implementation of generative LM 730 including a transformer encoder-decoder. For example, assume that input text such as “Who discovered gravity” is tokenized (e.g., by tokenizer 710 in Figure 7A ) into tokens such as words, and each token is encoded (e.g., by embedding component 720 in Figure 7A ) into a corresponding embedding (e.g., of size 512). Since these token embeddings generally do not represent the position of the token in the input sequence, position encodings can be added to each token embedding using any known technique to encode the sequential relationship and context of the tokens in the input sequence. Thus, the (e.g., resulting) embeddings can be applied to one or more encoders 735 of generative LM 730.

[0214] In example implementations, the encoder 735 forms an encoder stack in which each encoder includes a self-attention layer and a feedforward network. In an example transducer architecture, each token (e.g., word) flows through a separate path. Thus, each encoder can accept a sequence of vectors, pass each vector through a self-attention layer, then through a feedforward network, and then pass up to the next encoder in the stack. Any known self-attention technique can be used. For example, to compute a self-attention score for each token (word), a query vector, a key vector, and a value vector can be created for each token, a self-attention score for a pair of tokens can be computed by dot product of the query vector with the corresponding key vector, normalizing the resulting scores, multiplying by the corresponding value vector, and summing the weighted value vectors. The encoder can apply multi-head attention in which the attention mechanism is applied multiple times in parallel with different learned weight matrices. Any number of encoders can be concatenated to generate a context vector that encodes the input. The attention projection layer 740 can convert the context vector to an attention vector (keys and values) for the decoder 745.

[0215] In example implementations, the decoder 745 forms a decoder stack in which each decoder includes a self-attention layer, an encoder-decoder self-attention layer that attends to relevant portions of the input sequence using attention vectors (keys and values) from the encoder, and a feedforward network. As with the encoder 735, in an example transducer architecture, each token (e.g., word) flows through a separate path in the decoder 745. During a first pass, the decoder 745, the classifier 750, and the generation mechanism 755 can generate a first token, and the generation mechanism 755 can apply the generated token as input during a second pass. This process can be repeated in a loop, generating tokens (e.g., words) in turn and adding them to the output of the previous pass, and applying the token embeddings of the composite sequence with positional encodings as input to the decoder 745 during subsequent passes, generating one token at a time sequentially (known as autoregressive) until a symbol or token is predicted that indicates the end of the response. In each decoder, the self-attention layer is typically restricted to attending only to previous positions in the output sequence by applying a masking technique (e.g., setting future positions to negative infinity) prior to the softmax operation. In example implementations, the operation of the encoder-decoder attention layer is similar to the (e.g., multi-head) self-attention in the encoder 735, except that it creates its queries from the layer below it and takes its keys and values (e.g., matrices) from the output of the encoder 735.

[0216] Thus, the decoder 745 can output some decoded (e.g., vector) representation of the input applied during a particular pass. The classifier 750 can include a multi-class classifier that includes: one or more neural network layers that project the decoded (e.g., vector) representation into corresponding dimensions (e.g., one dimension for each supported word or token in the output vocabulary); and a softmax operation that converts logical values ​​(logits) into probabilities. Thus, the generation mechanism 755 can select or sample words or tokens based on corresponding predicted probabilities (e.g., select the word with the highest predicted probability) and append it to the output from the previous pass, thereby sequentially generating each word or token. The generation mechanism 755 can repeat this process, triggering consecutive decoder inputs and corresponding predictions, until a symbol or token representing the end of the response is selected or sampled, at which point the generation mechanism 755 can output the generated response.

[0217] Figure 7C is a block diagram of an example embodiment of a generative LM 730 including a decoder-only converter architecture. For example, Figure 7C The decoder 760 can be used with Figure 7B The decoder 745 operates similarly, except Figure 7C Each decoder 760 omits the encoder-decoder self-attention layer (because there is no encoder in this embodiment). Therefore, the decoders 760 can form a decoder stack, where each decoder includes a self-attention layer and a feed-forward network. In addition, instead of encoding the input sequence, a symbol or marker indicating the end of the input sequence (or the beginning of the output sequence) can be appended to the input sequence, and the resulting sequence (e.g., with a corresponding embedding of the positional encoding) can be applied to the decoder 760. Figure 7B Like the decoder 745 of FIG. 7 , each token (e.g., word) can flow through a separate path in the decoder 760, and the decoder 760, classifier 765, and generation mechanism 770 can sequentially generate one token at a time using autoregression until a symbol or token indicating the end of the response is predicted. The classifier 765 and generation mechanism 770 can be used with Figure 7B The classifier 750 and generation mechanism 755 operate similarly, with the generation mechanism 770 selecting or sampling each successive output token based on the corresponding predicted probability and appending it to the output from the previous pass, generating each token sequentially until a symbol or token representing the end of the response is selected or sampled. These and other architectures described herein are merely examples, and other suitable architectures may be implemented within the scope of the present disclosure.

[0218] Example computing device

[0219] Figure 8A block diagram of an example computing device 800 suitable for implementing some embodiments of the present disclosure is provided. The computing device 800 can include an interconnection system 802 coupling the following components: a memory 804, one or more central processing units (CPUs) 806, one or more graphics processing units (GPUs) 808, a communication interface 810, input / output (I / O) ports 812, input / output components 814, a power supply 816, one or more presentation components 818 (e.g., a display), and one or more logical units 820. In at least one embodiment, the computing device 800 can include one or more virtual machines (VMs), and / or any component thereof can include a virtual component (e.g., a virtual hardware component). For a non-limiting example, the one or more GPUs 808 can include one or more vGPUs, the one or more CPUs 806 can include one or more vCPUs, and / or the one or more logical units 820 can include one or more virtual logical units. Thus, the computing device 800 can include discrete components (e.g., a full GPU dedicated to the computing device 800), virtual components (e.g., a portion of a GPU dedicated to the computing device 800), or a combination thereof.

[0220] Although Figure 8 various blocks of the computing device are shown as being connected via the interconnection system 802 having a bus, this is not intended to be limiting and is for clarity only. For example, the presentation components 818 such as a display device can be considered an I / O component 814 (e.g., if a touchscreen is considered an I / O component 814). As another example, a CPU 806 and / or GPU 808 can include memory (e.g., the memory 804 can represent a storage device in addition to the memory of the GPU 808, CPU 806, and / or other components). In other words, the components of the computing device can be connected in general by one or more busses, point-to-point connections, or other communications interfaces, and the interconnection system 802 can represent one or more busses, point-to-point connections, or other communications interfaces as appropriate. Furthermore, in at least one embodiment, the computing device 800 can be a multi-processor system and, therefore, can include two or more Figure 8 The computing device is merely illustrative of one implementation and other devices such as “thick” clients, “thin” clients, nettops, netbooks, ultrabooks, notebooks, tablets, mobile devices, hand-held devices, game consoles, electronic control units (ECUs), virtual reality systems, and / or other device or system types are within the scope of the computing device. Figure 8 The computing device is merely illustrative of one implementation and other devices such as “thick” clients, “thin” clients, nettops, netbooks, ultrabooks, notebooks, tablets, mobile devices, hand-held devices, game consoles, electronic control units (ECUs), virtual reality systems, and / or other device or system types are within the scope of the computing device.

[0221] The interconnection system 802 can represent one or more links or buses, such as an address bus, a data bus, a control bus, or a combination thereof. The interconnection system 802 can include one or more link or bus types, such as an Industry Standard Architecture (ISA) bus, an Extended Industry Standard Architecture (EISA) bus, a Video Electronics Standards Association (VESA) bus, a Peripheral Component Interconnect (PCI) bus, a Peripheral Component Interconnect Express (PCIe) bus, and / or another type of bus or link. In some embodiments, there are direct connections between components. As an example, the CPU 806 can be directly connected to the memory 804. Also, the CPU 806 can be directly connected to the GPU 808. Where there are direct or point-to-point connections between components, the interconnection system 802 can include a PCIe link to perform the connection. In these examples, a PCI bus need not be included in the computing device 800.

[0222] The memory 804 can include any of a wide variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computing device 800. Computer-readable media can include both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media can comprise computer storage media and communication media.

[0223] Computer storage media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, and / or other data types. For example, the memory 804 can store computer readable instructions (e.g., which represent programs and / or program elements, such as an operating system). Computer storage media can include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing device 800. Computer storage media, as used herein, does not include signals per se.

[0224] Computer storage media can include computer-readable instructions, data structures, program modules, and / or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" can refer to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, computer storage media can include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of the above should also be included within the scope of computer readable media.

[0225] The CPUs 806 can be configured to execute at least some of the computer-readable instructions in order to control one or more components of the computing device 800 to perform one or more of the methods and / or processes described herein. Each of the CPUs 806 can include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of handling a large number of software threads concurrently. The CPUs 806 can include any type of processors and can include different types of processors depending on the type of computing device 800 being implemented (e.g., processors with fewer cores for mobile devices and processors with more cores for servers). For example, depending on the type of computing device 800, the processors can be Advanced RISC Machines (ARM) processors implemented using reduced instruction set computing (RISC) or x86 processors implemented using complex instruction set computing (CISC). The computing device 800 can include one or more CPUs 806 in addition to one or more microprocessors or complementary co-processors such as math co-processors.

[0226] In addition or alternatively to CPU 806, GPU 808 can be configured to execute at least some computer-readable instructions to control one or more components of computing device 800 to perform one or more methods and / or processes described herein. GPU(s) 808 can be integrated GPUs (e.g., with CPU(s) 806) and / or GPU(s) 808 can be discrete GPUs. In embodiments, GPU(s) 808 can be co-processors to CPU(s) 806. Computing device 800 can use GPU(s) 808 to render graphics (e.g., 3D graphics) or perform general-purpose computing. For example, GPU(s) 808 can be used for general-purpose computing on GPUs (GPGPU). GPU(s) 808 can include hundreds or thousands of cores capable of processing hundreds or thousands of software threads concurrently. GPU(s) 808 can generate pixel data for output images in response to rendering commands (e.g., rendering commands from CPU(s) 806 received via a host interface). GPU(s) 808 can include graphics memory, such as display memory, for storing pixel data or any other suitable data (e.g., GPGPU data). Display memory can be included as part of memory 804. GPU(s) 808 can include two or more GPUs operating in parallel (e.g., via a link). The link can connect the GPUs directly (e.g., using NVLINK) or through a switch (e.g., using NVSwitch). When combined together, each GPU 808 can generate pixel data or GPGPU data for different portions of an output or for different outputs (e.g., a first GPU for a first image and a second GPU for a second image). Each GPU can include its own memory or can share memory with other GPUs.

[0227] In addition or alternatively to CPU 806 and / or GPU 808, logic unit(s) 820 can be configured to execute at least some computer-readable instructions to control one or more components of computing device 800 to perform one or more methods and / or processes described herein. In embodiments, CPU(s) 806, GPU(s) 808, and / or logic unit(s) 820 can execute any combination of methods, processes, and / or portions thereof discretely or jointly. Logic unit(s) 820 can be part of and / or integrated with CPU(s) 806 and / or GPU(s) 808, and / or logic unit(s) 820 can be discrete components or otherwise external to CPU(s) 806 and / or GPU(s) 808. In embodiments, logic unit(s) 820 can be processors of CPU(s) 806 and / or GPU(s) 808.

[0228] Examples of logic units 820 include one or more processing cores and / or components thereof, such as data processing units (DPUs), tensor cores (TCs), tensor processing units (TPUs), pixel visual cores (PVCs), visual processing units (VPUs), graphics processing clusters (GPCs), texture processing clusters (TPCs), streaming multi-processors (SMs), tree traversal units (TTUs), artificial intelligence accelerators (AIAs), deep learning accelerators (DLAs), arithmetic logic units (ALUs), application specific integrated circuits (ASICs), floating point units (FPUs), input / output (I / O) elements, peripheral component interconnects (PCIs), or peripheral component interconnect express (PCIe) elements, and the like.

[0229] In various embodiments, one or more CPUs 806, one or more GPUs 808, and / or one or more logic units 820 are configured to execute one or more instances of a depth estimation model 146.

[0230] Communication interface 810 can include one or more receivers, transmitters, and / or transceivers that enable computing device 800 to communicate with other computing devices via electronic communication networks, including wired and / or wireless communication. Communication interface 810 can include components and functionality to enable communication over any of a number of different networks, such as wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, and the like), wired networks (e.g., communication over Ethernet or InfiniBand), low power wide area networks (e.g., LoRaWAN, SigFox, and the like), and / or the Internet. In one or more embodiments, logic units 820 and / or communication interface 810 can include one or more data processing units (DPUs) to transfer data received over a network and / or over interconnect system 802 directly to one or more GPUs 808 (e.g., memory in GPUs 808).

[0231] I / O ports 812 can enable the computing device 800 to logically couple to other devices including I / O components 814, presentation components 818, and / or other components, some of which can be built in to (e.g., integrated in) the computing device 800. Illustrative I / O components 814 include a microphone, mouse, keyboard, joystick, game pad, game controller, satellite dish, scanner, printer, wireless device, etc. The I / O components 814 can provide a natural user interface (NUI) that processes air gestures, voice, or other physiological inputs generated by a user. In some instances, inputs can be transmitted to an appropriate network element for further processing. A NUI can implement any combination of speech recognition, stylus recognition, facial recognition, biometric recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, and touch recognition (as described in more detail below) associated with a display of the computing device 800. The computing device 800 can include depth cameras, infrared cameras, RGB cameras, touch screens, and combinations of these, such as a stereoscopic camera system to provide a depth map.

[0232] A power supply 816 can include a hard-wired power supply, a battery power supply, or a combination thereof. The power supply 816 can supply power to the computing device 800 to enable the components of the computing device 800 to operate.

[0233] The presentation components 818 can include a display (e.g., a monitor, a touch screen, a television, a heads-up display (HUD), other display types, or combinations thereof), speakers, and / or other presentation components. The presentation components 818 can receive data from other components (e.g., the GPU 808, the CPU 806, the DPU, etc.) and output that data (e.g., as a

[0234] Example data center

[0235] Figure 9 An example data center 900 is shown, which can be used in at least one embodiment of the present disclosure. The data center 900 can include a data center infrastructure layer 910, a framework layer 920, a software layer 930, and an application layer 940.

[0236] As Figure 9As shown, the data center infrastructure layer 910 can include a resource orchestrator 912, grouped computing resources 914, and node computing resources (“node C.R.”) 916(1)-916(N), where “N” represents any whole, positive integer. In at least one embodiment, the node C.R.s 916(1)-916(N) can include, but are not limited to, any number of central processing units (CPUs) or other processors (including DPUs, accelerators, field programmable gate arrays (FPGAs), graphics processors or graphics processing units (GPUs), etc.), memory devices (such as dynamic read-only memory), storage devices (such as solid state drives or disk drives), network input / output (NW I / O) devices, network switches, virtual machines (VMs), power modules, and cooling modules, etc. In some embodiments, one or more of the node C.R.s 916(1)-916(N) can correspond to a server having one or more of the above-described computing resources. Further, in some embodiments, the node C.R.s 916(1)-916(N) can include one or more virtual components, such as a vGPU, a vCPU, etc., and / or one or more of the node C.R.s 916(1)-916(N) can correspond to a virtual machine (VM).

[0237] In at least one embodiment, the grouped computing resources 914 can include separate groupings of node C.R.s 916 housed within one or more racks (not shown), or housed within a number of racks (also not shown) within various geographic locations of a data center. The separate groupings of node C.R.s 916 within the grouped computing resources 914 can include groupings of computing, network, memory, or storage resources that can be configured or allocated to support one or more workloads. In at least one embodiment, several node C.R.s 916 including CPUs, GPUs, DPUs, and / or other processors can be grouped within one or more racks to provide computing resources to support one or more workloads. The one or more racks can also include any number of power modules, cooling modules, and / or network switches in any combination.

[0238] The resource orchestrator 912 can configure or otherwise control the one or more node C.R.s 916(1)-916(N) and / or the grouped computing resources 914. In at least one embodiment, the resource orchestrator 912 can include a software design infrastructure (SDI) management entity for the data center 900. The resource orchestrator 912 can include hardware, software, or some combination thereof.

[0239] In at least one embodiment, as Figure 9As shown, the framework layer 920 can include a job scheduler 933, a configuration manager 934, a resource manager 936, and a distributed file system 938. The framework layer 920 can include a framework that supports software 932 of the software layer 930 and / or one or more applications 942 of the application layer 940. The software 932 or the applications 942 can include web-based service software or applications, respectively, such as service software or applications provided by Amazon Web Services, Google Cloud, and Microsoft Azure. The framework layer 920 can be, but is not limited to, a free and open-source software web application framework, such as Apache Spark TM (hereinafter “Spark”) that can utilize the distributed file system 938 for large-scale data processing (e.g., “big data”). In at least one embodiment, the job scheduler 933 can include a Spark driver for facilitating scheduling of workloads supported by various layers of the data center 900. In at least one embodiment, the configuration manager 934 can be capable of configuring different layers, such as the software layer 930 and the framework layer 920 including Spark and the distributed file system 938 for supporting large-scale data processing. The resource manager 936 can be capable of managing clustered or grouped computing resources mapped to or allocated for supporting the distributed file system 938 and the job scheduler 933. In at least one embodiment, the clustered or grouped computing resources can include the grouped computing resources 914 at the data center infrastructure layer 910. The resource manager 936 can coordinate with the resource orchestrator 912 to manage these mapped or allocated computing resources.

[0240] In at least one embodiment, the software 932 included in the software layer 930 can include software used by at least portions of the node C.R.s 916(1)-916(N), the grouped computing resources 914, and / or the distributed file system 938 of the framework layer 920. One or more types of software can include, but are not limited to, Internet web page search software, e-mail virus scanning software, database software, and streaming video content software.

[0241] In at least one embodiment, one or more application programs 942 included in application layer 940 can include one or more types of application programs used by at least portions of node C.R.s 916(1)-916(N), grouped computing resources 914, and / or distributed file system 938 of framework layer 920. One or more types of application programs can include, but are not limited to, any number of genomics applications, cognitive computing and machine learning applications, including training or inferencing software, machine learning framework software (e.g., PyTorch, TensorFlow, Caffe, etc.), and / or other machine learning applications used in conjunction with one or more embodiments.

[0242] In at least one embodiment, any of configuration manager 934, resource manager 936, and resource orchestrator 912 can implement any number and type of self-modification actions based on any number and type of data acquired in any technically feasible manner. Self-modification actions can relieve data center operators of data center 900 from making possibly poor configuration decisions and can avoid underutilized and / or poorly performing portions of a data center.

[0243] Data center 900 can include tools, services, software, or other resources for training one or more machine learning models or using one or more machine learning models to predict or infer information in accordance with one or more embodiments described herein. For example, a machine learning model can be trained in accordance with a neural network architecture by computing weight parameters using software and computing resources described above with respect to data center 900. In at least one embodiment, using weight parameters computed through one or more training techniques, a trained machine learning model corresponding to one or more neural networks can be used to infer or predict information using resources described above with respect to data center 900, such as but not limited to those described herein.

[0244] In at least one embodiment, data center 900 can use CPUs, application specific integrated circuits (ASICs), GPUs, FPGAs, and / or other hardware (or virtual computing resources corresponding thereto) to perform training and / or inference using resources described above. Moreover, one or more software and / or hardware resources described above can be configured as a service to allow users to train or perform information inference, such as image recognition, speech recognition, or other artificial intelligence services.

[0245] Example Network Environment

[0246] Network environments suitable for implementing embodiments of the present disclosure can include one or more client devices, servers, network-attached storage (NAS), other backend devices, and / or other device types. The client devices, servers, and / or other device types (e.g., each device) can be implemented on one or more instances of the computing device 800— e.g., each device can include similar components, features, and / or functionality of the computing device 800. Moreover, where backend devices (e.g., servers, NAS, etc.) are implemented, the backend devices can be included as part of the data center 900, an example of which is described in greater detail herein with respect to Figure 8 the computing device 800— e.g., each device can include similar components, features, and / or functionality of the computing device 800. Moreover, where backend devices (e.g., servers, NAS, etc.) are implemented, the backend devices can be included as part of the data center 900, an example of which is described in greater detail herein with respect to Figure 9 the computing device 800— e.g., each device can include similar components, features, and / or functionality of the computing device 800. Moreover, where backend devices (e.g., servers, NAS, etc.) are implemented, the backend devices can be included as part of the data center 900, an example of which is described in greater detail herein with respect to

[0247] Components of the network environment can communicate with each other by way of the network, which can be wired, wireless, or both. The network can include multiple networks, or network segments. For instance, the network can include one or more wide area networks (WANs), one or more local area networks (LANs), one or more public networks (such as the Internet and / or the public switched telephone network (PSTN)), and / or one or more private networks. Where the network includes a wireless telecommunications network, components such as base stations, communication towers, or even access points (among other components) can provide wireless connectivity.

[0248] Compatible network environments can include one or more peer-to-peer network environments (in which case servers can not be included in the network environment), as well as one or more client-server network environments (in which case one or more servers can be included in the network environment). In a peer-to-peer network environment, functionality described herein with respect to servers can be implemented on any number of client devices.

[0249] In at least one embodiment, the network environment can include one or more cloud-based network environments, distributed computing environments, combinations thereof, and the like. A cloud-based network environment can include a framework layer, a job scheduler, a resource manager, and a distributed file system implemented on one or more servers, which can include one or more core network servers and / or edge servers. The framework layer can include a framework for supporting one or more applications of a software layer and / or an application layer. The software or applications can include network-based service software or applications, respectively. In embodiments, one or more client devices can use the network-based service software or applications (e.g., by accessing the service software and / or applications via one or more application programming interfaces (APIs)). The framework layer can be, but is not limited to, a type of free and open-source software web application framework, such as Hadoop®, which can use the distributed file system for large-scale data processing (e.g., “big data”).

[0250] The cloud-based network environment can provide cloud computing and / or cloud storage that performs any combination of the computing and / or data storage functions described herein (or one or more portions thereof). Any of these various functions can be distributed across multiple locations from a central or core server (e.g., across one or more data centers in a state, region, country, globally, etc.). The core server can designate at least a portion of the functions to an edge server if the connection to the user (e.g., client device) is relatively close to the edge server. The cloud-based network environment can be private (e.g., limited to a single organization), public (e.g., available to many organizations), and / or a combination thereof (e.g., a hybrid cloud environment).

[0251] The client device can include at least some components, features, and functionality of the example computing device 800 described herein with respect to Figure 8 As examples and not by way of limitation, the client device can embody a personal computer (PC), a laptop computer, a mobile device, a smartphone, a tablet computer, a smartwatch, a wearable computer, a personal digital assistant (PDA), an MP3 player, a virtual reality headset, a global positioning system (GPS) or device, a video player, a video camera, a surveillance device or system, a vehicle, a watercraft, an aircraft, a virtual machine, a drone, a robot, a handheld communication device, a hospital device, a gaming device or system, an entertainment system, an in-vehicle computer system, an embedded system controller, a remote control, an appliance, a consumer electronic device, a workstation, an edge device, any combination of these described devices, or any other suitable device.

[0252] The present disclosure can be described in the general context of machine-usable instructions or computer code, including computer-executable instructions such as program modules, being executed by a computer or other machine, such as a personal digital assistant or other handheld device. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. The present disclosure can be practiced in a variety of system configurations, including hand-held devices, consumer electronics, general- purpose computers, more specialty computing devices, and the like. The present disclosure can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.

[0253] As used herein, the term "and / or," with respect to a listing of two or more elements, means that at least one of the listed elements is present. For example, "A and / or B" is intended to cover A only, B only, or both A and B. Further, "at least one of A or B" is intended to cover at least one of A, at least one of B, or at least one of both A and B.

[0254] The subject matter of the present disclosure is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this disclosure. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms "step" and / or "block" might be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.

Claims

1. A method comprising: generating, based at least on stereo features of a first image in a stereo pair of images, a depth map associated with the first image, the stereo features generated based at least on a first set of feature maps of the first image and a computed feature correlation between the first set of feature maps and a second set of feature maps of a second image in the stereo pair of images; generating a confidence map representing a probability that a depth value in the generated depth map is accurate; updating one or more portions of the generated depth map based at least on the confidence map; and performing one or more operations associated with an autonomous or semi-autonomous machine based at least on the generated depth map after the update.

2. The method of claim 1, wherein the stereo features of the first image in the stereo pair of images are associated with a disparity between corresponding pixels in the first image and the second image in the stereo pair of images.

3. The method of claim 1, wherein generating the depth map associated with the first image comprises: applying one or more convolutional layers to the stereo features.

4. The method of claim 1, wherein generating the confidence map comprises: applying one or more convolutional layers and an activation function to the stereo features.

5. The method of claim 4, wherein the activation function is configured to output a value between 0 and 1, inclusive.

6. The method of claim 1, wherein the method is performed using a machine learning model, and wherein the machine learning model is jointly trained to generate a depth map and a confidence map corresponding to the depth map.

7. The method of claim 1, wherein the method is performed using a machine learning model, and wherein the machine learning model is trained to generate a confidence map after being trained to generate a depth map.

8. The method of claim 1, wherein updating the one or more portions of the generated depth map based at least on the confidence map comprises: removing one or more original depth values from the depth map using the confidence map as a mask.

9. The method of claim 1, wherein the first set of feature maps corresponds to a set of feature channels.

10. At least one processor comprising: one or more circuits to: generate, based at least on stereo features of a first image in a stereo pair of images, a depth map associated with the first image, the stereo features generated based at least on a first set of feature maps of the first image and a computed feature correlation between the first set of feature maps and a second set of feature maps of a second image in the stereo pair of images; generate a confidence map representing a probability that a depth value in the generated depth map is accurate; update one or more portions of the generated depth map based at least on the confidence map; and perform one or more operations associated with an autonomous or semi-autonomous machine based at least on the generated depth map after the update.

11. The at least one processor of claim 10, wherein the processor is included in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system to perform simulation operations; a system to perform digital twin operations; a system to perform optical transport simulations; a system to perform collaborative content creation of 3D assets; a system to perform deep learning operations; Systems implemented using edge devices; Systems for generating or presenting at least one of virtual reality content, augmented reality content, or mixed reality content; Systems implemented using robots; Systems for performing conversational AI operations; Systems implementing one or more large language models; Systems implementing one or more visual language models (VLMs); Systems implementing one or more multi-modal language models (MMLMs); Systems implementing one or more machine learning models used as inference microservices, the inference microservices including the one or more machine learning models and one or more operating system (OS) level virtualization packages; Systems for generating synthetic data; Systems including one or more virtual machines (VMs); Systems implemented at least in part in a data center; or Systems implemented at least in part using cloud computing resources.

12. The at least one processor of claim 10, wherein the stereo feature of the first image in the stereo pair of images is associated with a disparity between a corresponding pixel in the first image and the second image in the stereo pair of images.

13. The at least one processor of claim 10, wherein generating the depth map associated with the first image comprises: applying one or more convolutional layers to the stereo feature.

14. The at least one processor of claim 10, wherein generating the confidence map comprises: applying one or more convolutional layers and an activation function to the stereo feature.

15. The at least one processor of claim 14, wherein the activation function is configured to output a value between 0 and 1, inclusive.

16. The at least one processor of claim 10, wherein updating the one or more portions of the generated depth map based at least on the confidence map comprises: removing one or more original depth values from the depth map using the confidence map as a mask.

17. The at least one processor of claim 10, wherein the one or more circuits execute a machine learning model, and wherein the machine learning model is jointly trained to generate a depth map and a confidence map corresponding to the depth map.

18. The at least one processor of claim 10, wherein the one or more circuits execute a machine learning model, and wherein the machine learning model is trained to generate a confidence map after being trained to generate a depth map.

19. A system comprising: one or more processors to cause performance of one or more control operations related to a machine based at least on a final depth map generated using one or more stereo cameras of the machine, the final depth map generated based at least on: calculating an initial depth map and a confidence map corresponding to the initial depth map using one or more machine learning models, and adjusting one or more depth values of the initial depth map using the confidence map.

20. The system of claim 19, wherein the system is included in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; a system for performing optical transport simulation; a system for performing collaborative content creation of 3D assets; a system for performing deep learning operations; systems implemented using edge devices; A system for generating or presenting at least one of virtual reality content, augmented reality content, or mixed reality content; A system implemented using a robot; A system for performing conversational AI operations; A system implementing one or more large language models; A system implementing one or more visual language models (VLMs); A system implementing one or more multi-modal language models (MMLMs); A system implementing one or more machine learning models that function as inference microservices, the inference microservices including the one or more machine learning models and one or more operating system (OS) level virtualization packages; A system for generating synthetic data; A system including one or more virtual machines (VMs); A system implemented at least in part in a data center; or A system implemented at least in part using cloud computing resources.

Images