Shenron Radar Architecture Breakdown

This document provides a precise architectural analysis of the Shenron radar simulation pipeline, focusing on ownership, energy flow, and multi-radar extensibility.

🏗️ Radar Abstraction & Ownership

Radar Instance Representation: Represented as a radar class in ConfigureRadar.py. It is a configuration-heavy object containing both hardware specs (frequency, bandwidth) and physics parameters (beamwidth, gain).
Signal Generation Ownership: Each ShenronRadarModel (in model_wrapper.py) own its own radar_obj. The pipeline is private to the instance; radars share the input Semantic LiDAR but do not share intermediate artifacts like ADC cubes or calculated losses.
Metadata Storage: All sensor-specific metadata (mount pose, FOV, waveform, noise floor) is stored as attributes of the radar class. It is accessed by name (e.g., radar_type='awrl1432') during model initialization.
Sequential vs Parallel: Processing is currently sequential. Within a single frame, the orchestrator iterates through defined radar profiles, generating one set of ADC samples and one point cloud at a time.

⚡ Energy Flow & Reuse

Reflected Energy Stage: First computed in Sceneset.py within the get_loss_3 function.
Energy Form: Linear power (normalized unitless factor representing RCS + Path Loss).
Storage Granularity: Stored per-point in a 1D array of length $N_{pts}$.
Reuse vs Recompute: It is currently recomputed for every radar profile. Even if the points are identical, get_loss_3 is called fresh for each radar instance to account for radar-specific gains.
Radar-Agnostic Stages: Only the raw semantic_lidar_data ingestion and the basic axis-swap in lidar.py are truly radar-agnostic. Once the data enters Cropped_forRadar, it becomes radar-dependent.

🌐 Coordinate Frames & Angular Knowledge

Transformation Point: Points are transformed into radar-local coordinates in lidar.py inside Cropped_forRadar via the rotate_points function and mount-offset subtraction (e.g., CARLA_X - 2.0).
Derived Quantities: Azimuth (theta) and Elevation (elev_angle) are computed derivationally in specularpoints() (Lines 221-222) before being passed to the loss function. They are not currently stored in the point structure.
Re-casting Rays: Points are represented in Cartesian XYZ; azimuth and elevation can be (and are) computed analytically without re-casting rays.
Occlusion & Incidence: Occlusion is strictly radar-dependent (calculated from the radar.center viewpoint). Incidence angle is calculated relative to surface normals and is partially shared as it is scene-dependent, but its power-contribution is radar-dependent.

📉 Loss / Gain Modeling

Modular Support: Modular support is limited. Code uses fixed functions (get_loss_3); there is no plug-in architecture for gain blocks yet.
Application Relative Order: Applied in the following order: Range Loss ($1/R^2$ transmit) → Material Permittivity Loss → Surface Roughness Loss → Vertical Antenna Gain. Horizontal gain is currently missing.
Mathematical Domain: Applied multiplicatively in linear space.
Scaling Mechanism: Scaling is currently injected via the radar.gain and radar.vertical_beamwidth properties passed into the physics functions.

🛡️ Multi‑Radar Safety

Shared Tick Structures: The incoming semantic_lidar_data numpy array is the primary shared structure.
Contamination Risk: Low. lidar.py and Sceneset operate on slices or copies (e.g., skew_pc, new_pc). Internal modifications to pc[:, 4] exist but usually target local copies.
Immutability: Not strictly enforced by Python, but the workflow treats the input LiDAR as a read-only source.
Attribute Cloning: Introducing per-radar antenna loss would not require cloning the whole attribute list; it simply requires a new temporary array produced by the radar-specific loss function.

📡 ADC & Noise Injection

Thermal Noise Stage: Added during the ADC synthesis in heatmap_gen_fast.py (Line 146). It is added to the clean signal after beamforming.
ADC Sharing: Strictly per-radar. ADC cubes are not shared across profiles.
SNR Variation: Easily introduced via the radar.noise_amp property in the profile.
Power Preservation: Signal power and noise power are calculated separately and summed; they are not tracked as separate streams after summation.

⚙️ Configuration & Extensibility

Profile Loading: Hardcoded Python classes/dictionaries in ConfigureRadar.py.
Sensor LUTs: Existing precedent in lidar.py for semantic-to-material mapping tables.
Radiation Patterns: Can be attached as scalar beamwidths (current) or arrays/LUTs (feasible).
Runtime Switching: Fully supported via the ShenronRadarModel wrapper.

🚀 Performance & Scaling

Point Budget: 5,000 – 15,000 points per radar per frame (post-cropping).
LUT Performance: Highly acceptable; NumPy vectorized lookups for material/angle coefficients are not a bottleneck.
Memory Pressure: Low for point data. High for ADC cubes and large Range-Doppler FFT matrices if many radars run concurrently.

🐞 Validation & Debugging

Logging Hooks: The last_metrology dictionary in model_wrapper.py serves as the primary hook for internal diagnostics.
Energy Annotation: The internal loss array is calculated but usually discarded; it is not currently appended to the return point cloud.
Comparison Hook: Radars can be compared frame-by-frame by running two model instances on the same semantic_lidar_data buffer.

🔮 Future‑Proofing

MIMO/Virtual Antennas: Logic lives in heatmap_gen_fast.py inside the torch-accelerated phase-delay loop.
Physics Separation: A partial separation exists. Sceneset.py is "Scene Physics" (Reflection/Scattering), while ConfigureRadar.py is "Sensor Physics."
Antenna Pattern Logic: Logically belongs to the Sensor Model (ConfigureRadar) but must be applied during the Scene Physics stage to attenuate incident rays before they become ADC signals.

Generated by Antigravity AI | Fox Radar ADAS Pipeline Architecture Review

6.3 KiB Raw Blame History