Shenron Radar Physics: Issue Analysis & Resolution Plan

This document details the root causes behind the three radar anomalies observed during Iteration 08, leveraging the radar physics models and signal processing math in the pipeline.

Issue 1: High False Velocities (>25 m/s) on Static Buildings

Observation: Static buildings exhibit radial velocities $> 25\text{ m/s}$ (moving away) when the ego vehicle turns or drives fast, particularly on far-off structures.

Physics Root Cause: Doppler Aliasing (Nyquist Wrap-Around) FMCW radars measure radial velocity by measuring the phase shift between consecutive chirps. There is a fundamental physics hardware limit called the **Maximum Unambiguous Velocity ($V_{max}$)**.

If an object approaches faster than $V_{max}$, the phase shift exceeds $180^\circ$ and "wraps around," making a fast-approaching object look like it's fast-receding (aliasing).

The Math: $V_{max} = \frac{\lambda}{4 \cdot T_{rep}}$
AWRL1432 Profile: Frequency = 77 GHz ($\lambda \approx 3.89\text{ mm}$), Chirp Repetition ($T_{rep}$) = $36.4\mu s$.
$V_{max} = \frac{3.89\text{ mm}}{4 \times 36.4\mu s} \approx \mathbf{26.75\text{ m/s}}$ (approx. 96 km/h).

Why it happens during turns/driving: If your Ego vehicle is driving straight at 100 km/h (27.7 m/s), a static building dead ahead is approaching you at -27.7 m/s. Because this exceeds the -26.75 m/s limit of the AWRL1432 profile, the FFT wraps it around to the positive side of the spectrum, outputting roughly +25.8 m/s (moving away).

Resolution Plan: This perfectly matches real-world 77GHz hardware limitations! To fix it, we must either increase the pulse repetition frequency (lower chirp_rep in ConfigureRadar.py), or implement a multi-Doppler ambiguity resolution algorithm in the processor.

Issue 2: NPC Vehicle "Disappearing" During Turns

Observation: The NPC vehicle vanished from the awrl1432 radar when making a turn or presenting non-flat angles, but a background tree remained visible. The older radarbook radar did not lose the NPC.

Physics Root Cause: Specular Deflection vs. Diffuse Wavelength Penalty In lidar.py, we assigned cars the "Metal" material type, which has an extremely low roughness score (0.0001). This makes vehicles act like perfect mirrors.

Straight Lines: When the NPC is driving straight ahead, its rear bumper is perfectly perpendicular to your radar. The radar beam bounces directly back (Specular Reflection), creating a massive "flash" of energy.
Turning: When the NPC turns, its body angle changes. Like pointing a flashlight at a mirror tilted 45 degrees, the radar beam bounces off the car and scatters into the simulated sky or road.
Why did radarbook see it, but awrl1432 failed? When specular reflection fails, radar relies on "Diffuse Scattering" (rough edges like tires and door handles that scatter energy everywhere). The Radar Equation states that return power scales with the square of the wavelength ($\lambda^2$).
- radarbook (24 GHz) $\lambda = 12.5\text{ mm}$
- awrl1432 (77 GHz) $\lambda = 3.89\text{ mm}$
- $(12.5 / 3.89)^2 \approx \mathbf{10.3\times}$ More Power. Because 77GHz wavelengths are so small, diffuse scattering is incredibly weak. The diffuse return of the turning car fell below the CFAR threshold for the awrl1432, but stayed above the threshold for the radarbook.

Resolution Plan: We need to increase the roughness coefficient for the "Metal" material in lidar.py. Real cars are shiny, but their complex geometry (grilles, mirrors, rims) scatters a lot of energy. A slightly higher roughness will ensure they return energy continuously, even at high deflection angles.

Issue 3: "Ghost Points" Following the NPC Direction

Observation: Ghost points appear very close to the ego vehicle. They do not move relative to the ego, but they continuously point in the exact same azimuthal direction as the bright NPC vehicle.

Signal Processing Root Cause: Range Spectral Leakage (FFT Sidelobes) This is not a reflection from the road—this is a math artifact of the Fast Fourier Transform (FFT) inside the Signal Processor.

When the NPC vehicle is straight ahead, the specular "flash" is so incredibly loud (SNR > 60-80 dB) that its signal overwhelms the FFT.
An FFT assumes infinite periodic signals. When we window a finite ADC sample (256 samples), a perfect peak "leaks" energy into adjacent bins. These are called Sidelobes.
If the NPC is at 30 meters, its sidelobes will spread down into the 5m, 10m, and 15m range bins. Because these ghost peaks are literally pieces of the NPC's signal, they mathematically have the exact same Angle-of-Arrival (AoA), causing them to "point" at the NPC.

Resolution Plan:
1. Short-Range Blanking: All real-world ADAS radars mute the first 2-3 meters of data to ignore DC leakage, bumper reflections, and extreme sidelobes. We can implement a hard cutoff in radar_processor.py (e.g., range > 2.0m).
2. Stronger Windowing: The processor currently uses a Hann window. Changing it to a Blackman-Harris window will suppress sidelobes by -92dB, completely eliminating these ghost points at the cost of slightly thicker range bins.

Issue 4: Tree-Wall "Vertical Clumping"

Observation: Dense tree walls in CARLA create massive clumps of radar data that smear across the 2D range-azimuth map, masking targets and creating "Phantom Walls."

Physics Root Cause: Infinite-Height Integration By default, the C-SHENRON engine sums all LiDAR points within a 2D range-doppler bin equally. For a 15-meter tree, thousands of vertical points are integrated with full gain, creating a "Vertical Energy Bomb." This makes vertically large objects (trees/buildings) look 10-20x louder than horizontally large objects (cars).

Resolution (Iteration 14a): Gaussian Vertical Damping In real-world radars, the antenna has a limited vertical FOV (typically $\pm 10-20^\circ$). We implemented a Gaussian Beamwidth Pattern in Sceneset.py: $$G_{vertical} = \exp\left(-2.77 \cdot \left(\frac{\phi_{elev}}{\theta_{beam}}\right)^2\right)$$ This physically suppresses tree-top clutter by **>90%** while preserving the boresight lead-car at 100% gain ($0^\circ$ elevation).

Issue 5: The "Resolution Trap" (Context-Dependent Detections)

Observation: In complex city scenes (Frame 100), the lead car would physically vanish from the radar heatmap, but would reappear in open-road scenes (Frame 207).

Physics Root Cause: Global Normalization Dependency The engine previously used a global normalization factor $1/N_{total}$. In a city, $N_{total}$ is very large due to thousands of background points on buildings. This "stole" the energy budget from the smaller car targets. **A real radar return is not context-dependent.**

Resolution (Iteration 16): Area-Density Integration We replaced the dynamic $1/N_{total}$ with a **Fixed Density Reference** constant. This ensures that a car's brightness is governed purely by its **Radar Cross Section (RCS)** and **Range**, regardless of whether there are buildings behind it.
- The Result: A +234% Magnitude Recovery for distant targets and absolute signal stability across all scenario frames.

7.2 KiB Raw Blame History