4D Imaging Radar at the Edge 2026 — ARM Compute for Radar Point Clouds, Occupancy & Cross-Traffic Safety

Traditional automotive radar was a 2D sensor: it measured range and Doppler and left the third dimension ambiguous. A 4D imaging radar adds angular resolution in both azimuth and elevation, using dense MIMO arrays of dozens of transmit and receive channels, and returns a genuine point cloud — range, azimuth, elevation, radial velocity — at ten to twenty thousand points per frame. That changes the sensor from a detector into a mapping device, and it moves the compute question from the radar MCU to the edge node behind it.

This guide covers what 4D imaging radar actually outputs, where to split the processing pipeline, the bandwidth arithmetic that decides the split, and which ARM compute tier each half of the job needs.

What 4D Imaging Radar Changes

A camera degrades gracefully in rain, fog and darkness; a LiDAR gives precise geometry but struggles in precipitation and dust. Radar is unaffected by all three, and adding elevation means it can finally separate a pedestrian from the road surface, resolve objects under a truck, and map free space rather than only list detections. The trade is resolution: a good 4D radar resolves tens of centimetres where LiDAR resolves a few, so the two are complements, not substitutes.

The Processing Pipeline and Where to Split It

Every imaging radar runs the same chain: a range FFT per chirp, a Doppler FFT across chirps, an angle FFT across the virtual MIMO channel array, constant-false-alarm-rate detection, then clustering into points and finally a perception model over the point cloud. The first four stages are deterministic digital signal processing; the last is neural.

The split point matters because raw data is enormous. A representative cube of 256 range samples, 128 chirps, 12 transmitters and 8 receivers at 4 bytes per complex sample is roughly 12.6 MB per frame. At 20 frames per second that is about 250 MB/s per radar — and a vehicle or work cell may carry four to eight of them. If the point-cloud reduction happens on the sensor SoC, the same radar ships a few hundred kilobytes per frame instead.

The engineering rule that follows: do the FFT and detection work on the sensor, do the learning on the host. Pushing the cube across PCIe or Ethernet to a host GPU is possible, and some development platforms do it, but it multiplies interface cost and confines you to a wired, powered install. If raw-data access is a hard requirement for your research, size the link for 250 MB/s per radar and treat it as a camera-class data flow, not a sensor feed.

Choosing ARM Compute for Radar Point Clouds

Point-cloud perception is memory-bandwidth bound, not FLOP bound. Sparse convolutions, voxel grids and clustering touch scattered memory, so a tier with more usable bandwidth and a mature toolchain beats one with a taller TOPS number.

Interfaces, Time Sync and the Enclosure

Radar data usually arrives over 100BASE-T1 or 1000BASE-T1 automotive Ethernet, or over MIPI CSI-2 on development hardware. The moment a radar shares a decision with a camera, timestamping stops being optional: a 10 ms offset between a radar point and a camera frame is a metre of travel at highway speed, and a hard braking decision at a pedestrian crossing. Specify IEEE 802.1AS / IEEE 1588 hardware timestamping on every sensor and verify that the host keeps the same time base.

Sizing Rules and Specification Checklist

• Size by bandwidth, not TOPS. Estimate point count per frame and the memory traffic the perception model generates; that, not FLOPs, decides the tier
• Compress on the sensor. Keep the range-Doppler cube and antenna array inside the radar SoC; export detections and points
• One node per two to four radars. Below that the interface cost dominates; above it, timestamp skew and bandwidth pile up
• Keep the safety path separate. Run cross-traffic and emergency decisions on a lock-step MCU, not on the shared GPU
• Sync before you fuse. Insist on hardware timestamping and prove the offset with a moving-target test, not a datasheet
• Grade the enclosure to the mount, not the lab. A −40 to +85 °C sensor in a 0–50 °C cabinet is a wasted specification
• Log for the length of the incident review. Radar event data is compact enough to retain far longer than video — use an industrial SSD with a rated sustained write and known DWPD
• Validate with both modalities. Prove where the radar catches a failure the camera misses — that result, not the datasheet, justifies the budget

QSCompute supplies the ARM-side compute for radar perception — Jetson Orin modules and carrier boards, fanless wide-temperature ARM and x86 industrial PCs, and industrial NVMe storage sized for continuous sensor logging.