In the present state of automotive radar, machine learning engineers can’t work with camera-equivalent raw RGB images. As a substitute, they work with the output of radar constant false alarm rate (CFAR), which is analogous to computer vision (CV) edge detections. The communications and compute architectures haven’t kept pace with trends in AI and the needs of Level 4 autonomy, despite radar being a staple of auto‑level sensing for years.
The true 3D/4D “image” signal is as a substitute processed contained in the edge device. The radar outputs objects, or in some cases point clouds, which is analogous to a camera outputting a classical CV Canny edge‑detection image.
Centralized radar processing on NVIDIA DRIVE changes this model: Raw analog‑to‑digital converter (ADC) data moves right into a centralized compute platform. From there, a software-defined pipeline accelerated by dedicated NVIDIA Programmable Vision Accelerator (PVA) hardware handles the whole lot from raw ADC samples to point clouds, with the GPU reserved for AI usage at any stage in the information flow. In such a paradigm, machine learning AI systems aren’t constrained to edge detections, as a substitute they’ll utilize the complete fidelity radar image, offering ~100x increase in available bits of data.
By removing the high-power digital signal processor/microcontroller unit (DSP/MCU) inside edge compute radar, centralized radar returns to its radiofrequency (RF) roots with a streamlined printed circuit board (PCB). This design cuts unit costs by over 30% and reduces volume by roughly 20%, achieving an ultra-slim form factor. Leveraging the superior energy efficiency of central domain controllers, overall system power consumption drops by about 20%. This innovation not only reshapes hardware design but in addition aligns perfectly with global green energy trends.
On this blog, we explain how centralized radar processing works on DRIVE, covering:
- Why the usual radar model limits what higher levels of autonomy, especially L4 stack, can do with radar data
- How raw ADC data is ingested and moved into DRIVE memory
- How the PVA handles radar signal processing without consuming CPU or GPU
For this evaluation, NVIDIA collaborated with ChengTech, the primary raw radar partner joining the DRIVE platform, to validate centralized compute radar processing on DRIVE with production‑grade hardware.
At GTC 2026 last week, NVIDIA and ChengTech demonstrated this pipeline running in real time on DRIVE AGX Thor using production ChengTech radar units.
How centralized radar processing expands radar perception
Most production automotive radars use edge processing architecture. Each sensor unit integrates its own system on chip (SoC) or field‑programmable gate array (FPGA), runs a set signal‑processing chain on board, and outputs a sparse point cloud to the central advanced driver assistance system electronic control unit (ADAS ECU). This keeps integration straightforward and limits the bandwidth required between sensor and compute platform.
The tradeoffs, nonetheless, are noteworthy:
- Point clouds send only peak detections, and carry ~100x less data than the raw ADC samples produced by the radar frontend. For instance, the long-range radar in our configuration produces 6 MB of raw ADC per frame versus 0.064 MB as some extent cloud. Centralized architectures that ingest raw or frivolously processed radar can leverage more of the underlying signal statistics to offer perception gains.
- The radar duty cycle in edge processing is usually below 50% (the proportion of time the radar is transmitting), which usually means lower frame rates corresponding to ~20 frames per second (FPS) and/or reduced power on track. That’s workable for traditional ADAS triggers, nevertheless it leaves temporal resolution on the table for giant, time-aware models.
- Tight memory and bandwidth constraints of an edge‑radar ECU mean it must discard intermediate frequency‑domain products corresponding to range fast Fourier transform (range‑FFT) cubes, Doppler‑FFT cubes, and angle‑FFT maps, although these are precisely the signal views that recent learning‑based radar models and signal‑level fusion methods would most prefer to access, as shown in Raw High‑Definition Radar for Multi‑Task Learning (CVPR 2022) and T‑FFTRadNet: Object Detection with Swin Vision Transformers from Raw ADC Radar Signals (ICCV Workshops 2023).
- The radar signal-processing pipeline is fixed on edge hardware, subject to tight thermal and compute limits. Centralized processing allows the OEM or system integrator to enable deeper networks, higher input resolution, and multi‑sensor joint models that will be impractical on a small radar SoC.
L4 stacks are increasingly adopting large models and vision-language-action (VLA) architectures that learn directly from raw sensor data reasonably than from post-processed outputs. These systems profit from dense, low-level signals across all sensor modalities, the identical way vision models profit from raw camera frames reasonably than compressed features. For radar, meaning rethinking where and the way processing happens.
Centralized compute radar on NVIDIA DRIVE
Centralized radar processing addresses these limitations by relocating the signal processing chain from the sensor to the DRIVE platform. The RF front-end and antennas remain on the sensor hardware, but as a substitute of running a set embedded pipeline, the units stream raw ADC samples into DRIVE DRAM over a high-bandwidth link. All stages of radar signal processing run on DRIVE’s dedicated hardware PVA, where developers control the complete pipeline.
Three components make this work together:
1) Sensors configured for raw ADC output
2) A driver stack that ingests and synchronizes raw data into DRIVE memory
3) A PVA-based compute library that handles all radar DSP
Together, these pieces make radar a centrally managed, accelerator-backed modality on DRIVE, aligned with how cameras and lidar are already integrated in modern L4 architectures.
Moving raw ADC data into DRIVE memory
Step one is getting raw ADC data off the sensor and into central memory reliably and at scale. In our configuration, five sensors are deployed across the vehicle:
- One ChengTech 8T8R front radar
- 4 ChengTech 4T4R corner radars
All five units are configured to output raw ADC data as a substitute of embedded-processed point clouds. The combination raw data rate is roughly 540 MB/s across the array, in comparison with 4.8 MB/s for an equivalent point-cloud-based radar belt.
The ingestion stack handles this through platform-level radar drivers that:
- Configure sensors for raw-output modes
- Stream ADC frames into DRIVE DRAM on the required throughput
- Present radar frames through a consistent, hardware-agnostic API
- Share a hardware synchronization signal with camera capture so radar and image frames are aligned for multi-modal fusion and training
From the appliance’s perspective, radar data arrives as timestamped, synchronized buffers in DRIVE memory, ready for the signal processing stage.
Running radar signal processing on PVA
Once raw ADC buffers are in memory, the signal processing chain runs entirely on PVA, leaving the GPU free for downstream AI. The pipeline covers the usual stages of radar DSP:
- Range-FFT along the fast-time axis to supply a variety profile per chirp
- Doppler-FFT along the slow-time axis to estimate radial velocity per range bin
The PVA is designed for exactly this class of workload. Figure 3, below, illustrates the high-level architecture of PVA in DRIVE AGX Thor. At its core, the PVA engine is a complicated very long instruction word (VLIW), single instruction multiple data (SIMD) digital signal processor (DSP). It combines vector processing units (VPUs), a dedicated DMA engine, and on-chip local memory (VMEM) to deliver sustained, high-throughput FFT performance with deterministic memory access behavior.
PVA provides high performance with low power consumption and might run asynchronously alongside the CPU, GPU, and other accelerators on the DRIVE platform as a part of a heterogeneous compute pipeline. In a five-radar setup, running the complete radar library on PVA as a substitute of on the GPU can significantly reduce GPU utilization and free GPU capability for perception and planning workloads.
To support customizable pipelines, PVA Solutions offers a set of highly optimized, commonly used radar operators. This enables developers to assemble and customize pipelines without having to implement every kernel from scratch. As well as, the NVIDIA Programmable Vision Accelerator Software Development Kit (PVA SDK) is out there for developers who wish to construct their very own proprietary secret sauce.
In our configuration, the PVA processes raw data from all five radar units at 30 frames per second. All radar DSP work stays on the PVA, minimizing CPU and GPU usage and leaving those resources available for perception networks, planning modules, and other workloads. The PVA uses reserved bandwidth within the memory subsystem.
Intermediate outputs at each stage are written back to DRAM and remain accessible to the remaining of the stack. This implies:
- Range-Doppler cubes and angle-FFT heatmaps will be visualized or logged for evaluation.
- Perception models can devour pre-point-cloud representations directly.
- Multi-radar fusion can operate on the signal level before final detection, improving noise rejection and goal resolution across the sensor array.
The range‑Doppler map in Figure 4, above, exposes dense spectral structure that traditional edge‑processed radars never export. In Figure 5, below, the peaks of this range-Doppler map are extracted, angle finding is performed, producing a sparse point cloud.
Exposing radar signal data to perception and physical AI
Centralizing radar on DRIVE does greater than remove per-sensor SoCs or FPGAs. It augments what’s visible to the perception and AI systems running on the platform.
With intermediate radar data in DRAM, several patterns grow to be practical:
- Recent work corresponding to Raw High‑Definition Radar for Multi‑Task Learning (CVPR 2022) and T‑FFTRadNet: Object Detection with Swin Vision Transformers from Raw ADC Radar Signals (ICCV Workshops 2023) trains neural networks on raw ADC signals or range/Doppler/angle‑FFT representations as a substitute of only on sparse point clouds, enabling richer radar perception.
- Designing early fusion models that mix radar and camera features using synchronized, raw or pre-point-cloud data.
- Implementing coherent fusion across multiple radar units on the signal level to enhance coverage, suppress interference, and handle opposed conditions.
For L4 stacks that already treat cameras and lidar as first-class raw modalities, centralized radar closes the gap. Radar can take part in VLA-style training workflows and other large-model approaches at the identical level of knowledge fidelity as other sensors, using the identical centralized, software-defined infrastructure that DRIVE already provides.
Centralized compute radar as the long run of L4 perception
Centralized radar processing on DRIVE exists to repair a straightforward limitation: today’s standard radars give L4 stacks a sparse, scattered view of a much richer signal. By pulling radar into DRIVE as a software-defined, accelerator-backed modality, you get the complete radar signal in DRAM, processed on dedicated hardware as a substitute of the GPU, and aligned with cameras and lidar for models to learn from.
Built on this compute and software foundation, NVIDIA DRIVE Hyperion reference architecture can integrate radar into the identical centralized, software-defined pipeline as cameras and lidar, giving OEMs a production-oriented blueprint for centralized radar.
Getting began
To start out evaluating this approach, work together with your radar supplier to enable raw-output modes and collaborate together with your perception team on richer radar-based models and fusion.
To maneuver toward production, engage with supported radar vendors and other NVIDIA DRIVE ecosystem partners, and speak to your NVIDIA representative for access to PVA SDK and PVA Solutions.
Acknowledgements
Because of Mark Vojkovich, Mehmet Umut Demircin, Michael Chen, Balaji Holur, Sean Pieper, Mladen Radovic, Nicolas Droux, Kalle Jokiniemi, Ximing Chen, Romain Ygnace, Sharon Heruti, Jagadeesh Sankaran, Zoran Nikolic, Ching Hung, Yan Yin, Qian Zhan, Dian Luo, Rengui Zhuo (ChengTech), Feng Deng (ChengTech), Mo Poorsartep, Cassie Dai, and Wonsik Han for his or her contributions.
