CubeDN: Real-Time 3D Radar Drone Detection

• CubeDN is a 3D radar detection network that fuses dual mmWave radar cubes to simultaneously detect, localize, and classify small and large drones in real time.
• It employs a dual-radar configuration that overcomes poor elevation resolution by using complementary azimuth and rotated elevation views, achieving high precision and recall.
• The system integrates a 3D CNN encoder–decoder with 3D LNMS post-processing on a fused Doppler–Range–angle tensor to ensure robust performance in varied environments.

Searching arXiv for the specified papers to ground the article and disambiguate the term. CubeDN most commonly denotes the single-stage, end-to-end radar object detection network introduced for real-time drone detection in 3D space from dual mmWave radar cubes (Fang et al., 25 Aug 2025). It is designed for simultaneous detection, localization, and classification of small and large flying drones using low-cost millimeter-wave sensors, with a formulation centered on preserving full range–Doppler–angle correlations and compensating for poor elevation resolution through a dual-radar configuration. A separate usage appears in the Minecraft generative modeling paper "Dream-Cubed," where "CubeDN" is not an acronym or named method; there, the term can only be interpreted informally as the cube/block-based diffusion model family that operates directly on native block tokens (Merino et al., 22 Apr 2026).

1. Terminology, problem setting, and scope

In the radar literature, CubeDN addresses 3D drone detection rather than 2D object detection. The motivation is explicit: flying drones operate in 3D space, and precise altitude and 3D positioning are essential for navigation, tracking, and airspace safety/security. The problem is materially harder than road-user detection because drones are small, with the paper giving a 5-inch frame at 250 mm diagonal as an example (Fang et al., 25 Aug 2025).

The method is positioned against camera- and LiDAR-based pipelines whose performance degrades under poor illumination, bad weather, smoke, and dust, and against camera-based 2D systems that estimate depth from bounding box size. The paper instead adopts mmWave radar, emphasizing robustness to adverse conditions together with high range and Doppler resolution and the availability of modern single-chip devices that are low-cost and lightweight. Its central technical obstacle is that typical single-chip setups have poor elevation resolution, which impedes 3D detection.

A recurring point of clarification concerns the name itself. In "Dream-Cubed," the phrase does not denote an official model name; the paper explicitly states that CubeDN is not an acronym or named method there. Interpreting the term in that context refers only to the family of diffusion models that treat each voxel as a categorical cube token and generate $32 \times 32 \times 32$ Minecraft chunks conditioned on biome labels (Merino et al., 22 Apr 2026). The primary encyclopedic referent of CubeDN is therefore the radar detector, not the Dream-Cubed voxel generator.

2. Dual-radar sensing and 4D cube construction

CubeDN uses two identical Texas Instruments AWR1843Boost mmWave radars and DCA1000EVM data capture cards (Fang et al., 25 Aug 2025). The radars operate independently rather than as a cascaded array and are triggered and synchronized by an external controller to avoid mutual interference and align timestamps with camera and other sensors. The paper does not specify carrier frequency, bandwidth, chirp parameters, or windowing.

The elevation-resolution problem follows directly from the antenna geometry. Each radar uses a 3 Tx and 4 Rx MIMO array, yielding 12 virtual antennas, but only 2 virtual antennas are available for elevation while 8 are available for azimuth. This produces much lower elevation resolution, reported as approximately $60^\circ$, than azimuth resolution, reported as approximately $15^\circ$.

CubeDN addresses this asymmetry with a dual-radar configuration. Both radars enable only azimuth antennas, and one radar is rotated by $90^\circ$ so that its azimuth axis becomes elevation. The two devices are placed on the same plane with a 5 cm gap, smaller than the 11.6 cm range resolution, so their range and Doppler measurements are theoretically identical while azimuth and elevation differ.

FFT-based processing yields radar cubes with explicit Doppler, range, and angular structure. The horizontal radar produces a Doppler–Range–Azimuth cube,

$H \in \mathbb{R}^{D \times R \times A},$

and the vertical radar produces a Doppler–Range–Elevation cube,

$V \in \mathbb{R}^{D \times R \times E}.$

The system is configured with 255 Doppler bins and 256 range bins, compressed to 128 bins for runtime efficiency; native angle bins of 8 are padded to 32. According to the paper, this halves Doppler resolution to 0.094 m/s, sets range resolution to 0.116 m, and yields a maximum detection range of 15 m.

Fusion is multiplicative and preserves the cube structure. The two inputs are expanded to

$$H' \in \mathbb{R}^{D \times R \times A \times 1}, \qquad V' \in \mathbb{R}^{D \times R \times 1 \times E},$$

and combined into a fused four-dimensional tensor,

$\mathbf{Cube\_4D}[h, i, j, k] = \bm{H^{\prime}[h, i, j, 1] \times \bm{V^{\prime}[h, i, 1, k]$

where $h$ indexes Doppler, $i$ indexes Range, $60^\circ$0 indexes Azimuth, and $60^\circ$1 indexes Elevation. The stated purpose is to capture co-occurrence of strong signals in azimuth and elevation while preserving Doppler and Range and suppressing noise. This suggests that CubeDN treats the two radars less as independent views to be fused late and more as complementary factors in a joint 4D evidential representation.

3. Network formulation, targets, and post-processing

The network input is the fused 4D tensor $60^\circ$2 with dimensions $60^\circ$3, and the architecture is a 3D CNN encoder–decoder with skip connections between corresponding encoding and decoding feature maps (Fang et al., 25 Aug 2025). Each skip connection includes an extra 3D convolution to match feature dimensions for element-wise addition. The final layer is a classification head that reduces channel size to the number of classes.

The output is a class-indexed confidence cube over range, azimuth, and elevation:

$60^\circ$4

with $60^\circ$5, corresponding to small and large drones. Doppler is not predicted explicitly. Rather, Doppler is preserved in the input and used implicitly by the network during inference. The model also does not predict 3D bounding box size, orientation or yaw, or an explicit box parameterization.

Ground-truth drone positions are collected in Cartesian coordinates $60^\circ$6 and converted to radar polar coordinates $60^\circ$7. The training target is not a point label but a Gaussian mask in RAE space:

$60^\circ$8

where $60^\circ$9 for small drones and $15^\circ$0 for large drones, $15^\circ$1 sets the maximum confidence to 1.0 at $15^\circ$2, and values below 0.05 are set to 0. The paper states that the broader spread for large drones models class-dependent spatial extent in the confidence domain.

Training uses MSE only:

$15^\circ$3

with $15^\circ$4. Weighting terms, focal-loss variants, IoU-family losses, and auxiliary objectives are not specified.

Post-processing proceeds in two stages. First, CubeDN applies 3D LNMS. Elements above 0.01 confidence are sorted to form a candidate set $15^\circ$5; the highest-confidence element is selected; a larger Gaussian mask suppresses nearby elements; and the process repeats until distinct peaks remain. The suppression $15^\circ$6 is set to 3 for small drones and 5 for large drones. Second, each peak is validated by overlap-ratio filtering. Around a peak, a $15^\circ$7 RAE cube is cropped, a Gaussian mask is generated by the ground-truth equation, both are binarized with threshold 0.05, and an overlap ratio is computed. The empirical acceptance threshold is 0.5.

A common misconception is that CubeDN includes an explicit tracker because the abstract reports decimeter-level tracking accuracy. The paper states otherwise: conventional NMS beyond the location-based 3D LNMS and any explicit tracking filters such as Kalman or IMM are not specified, and the reported accuracy is based on per-frame localization error rather than an explicit tracker (Fang et al., 25 Aug 2025).

4. Training protocol, datasets, and empirical performance

The dataset comprises 41 sequences and approximately 123K raw frames collected at 10 Hz across multiple outdoor car parks and additional environments, including 2K frames at an outdoor gate entrance and 600 frames in an indoor office (Fang et al., 25 Aug 2025). The drone classes are a small 5-inch homemade quadcopter with 250 mm diagonal and a large DJI Inspire 3 with 685 mm diagonal. The paper reports overall train-plus-validation and test splits of approximately 64K and 13K frames, respectively. Frames before takeoff are removed, empty frames where the drone is beyond 15 m are kept, and frames with inaccurate ground truth greater than 2.5 cm RTK error are discarded.

Ground truth is sourced from RTK outdoors, with approximately 1 cm accuracy at 10 Hz, and from a Mo-Sys StarTracker indoors, with sub-millimeter accuracy at 60 Hz. All sensors are synchronized to radar frames. Training is performed per frame rather than as a time series. The paper reports training on an RTX 4090, i5-12600K, and 64 GB RAM for approximately three days over 70 epochs. Batch size, optimizer, learning rate, and data augmentation are not specified.

Evaluation is based on Average Precision and Average Recall under an Object Localization Error tolerance measured in bins over RAE space. OLE thresholds of 1, 3, and 5 bins reflect increasing tolerance, and OLE is described as analogous to IoU in 2D detection, although formal AP/AR formulas are not specified.

The principal detection results are as follows:

Setting	AP	AR
Small drone	95.25	82.77
Large drone	96.18	89.13
Small + large	93.32	84.76

The same evaluation also reports thresholded variants. For small drones, $15^\circ$8, $15^\circ$9, $90^\circ$0, and $90^\circ$1. For large drones, $90^\circ$2, $90^\circ$3, $90^\circ$4, and $90^\circ$5. For simultaneous small-plus-large detection, $90^\circ$6, $90^\circ$7, $90^\circ$8, and $90^\circ$9. The abstract summarizes this as overall 95% AP and 85% AR.

Localization accuracy is reported in meters by distance to radar. For CubeDN, small-drone error is 0.56 overall, with 0–3 m: 0.18, 3–6 m: 0.38, 6–9 m: 0.51, 9–12 m: 0.75, and 12–15 m: 1.07. Large-drone error is 0.52 overall, with 0–3 m: 0.13, 3–6 m: 0.40, 6–9 m: 0.45, 9–12 m: 0.62, and 12–15 m: 0.95. Dual-drone cases are similar, with small(+large) overall 0.53 and large(+small) overall 0.48. The trend is attributed to non-linear polar-to-Cartesian transformation and the growing effect of angular errors at longer ranges.

Relative to baselines, CubeDN substantially outperforms CubeCrop in AP/AR; one reported example is small-plus-large AP = 62.17 and AR = 73.99 for CubeCrop. For localization, mDrone reports small overall 1.38 and large overall 1.26, while a PointCloud method reports small overall 2.17 and large overall 1.47. The paper also reports generalization in an unseen outdoor environment with both drones, with approximately 40 cm mean localization error, approximately 94% AP, and approximately 85% AR, and indoors at 7 m in an office, with approximately 40 cm error, 86% AP, and 70% AR.

5. Runtime characteristics, robustness, and limitations

CubeDN is designed for real-time operation at 10 Hz (Fang et al., 25 Aug 2025). Radar data from two devices are transmitted via Ethernet/UDP and decoded with CUDA acceleration so that FFT and other heavy processing are reduced to milliseconds. End-to-end processing time is approximately 90 ms per frame, which is faster than the 10 Hz radar frame rate. Training hardware and inference hardware are both specified: the model is trained on an RTX 4090 and run for real-time inference on an RTX 3080 Ti laptop with a Ryzen 6900HX and 64 GB RAM. Model size and parameter count are not specified.

The claimed robustness derives from the sensing modality as much as from the network. The paper states that mmWave radar is resilient to poor illumination, adverse weather, smoke, and dust, and the collected data include varied conditions such as day, night, and windy settings. Generalization tests show strong outdoor performance and reasonable indoor performance despite clutter. A plausible implication is that the architecture’s preservation of full range–Doppler–angle correlations is particularly valuable when signal structure is partially degraded but not entirely lost.

The limitations are specific. Strict OLE = 1 produces lower AP/AR because the bin tolerance is tight. Indoor recall is reduced by static reflections and multi-path noise. The network does not output explicit velocity, box size, or orientation/yaw. Time-series tracking is not incorporated. Intrinsic and extrinsic calibration procedures beyond co-planarity, synchronization, and 5 cm separation are not specified. Future work identified by the paper includes multi-frame time-series integration and handling cluttered or dynamic scenes or moving mmWave sensors.

6. Relation to the Dream-Cubed usage

A separate line of work uses the label "CubeDN" only interpretively rather than as an official method name. In "Dream-Cubed: Controllable Generative Modeling in Minecraft by Training on Billions of Cubes," the paper explicitly states that CubeDN is not an acronym or named method (Merino et al., 22 Apr 2026). There, the phrase can be understood only as shorthand for the family of cube-based diffusion models operating directly on categorical Minecraft block tokens.

That model family differs fundamentally from the radar detector despite a shared emphasis on cube-structured inputs. Dream-Cubed’s models treat each voxel as a categorical cube token, generate $H \in \mathbb{R}^{D \times R \times A},$0 chunks conditioned on biome labels, and compare discrete masked diffusion (MD4) with continuous DDPM in block embedding space. The architecture is a single 280M-parameter 3D Diffusion Transformer backbone with 25 blocks, hidden dimension 768, 8 heads, and AdaLN conditioning on timestep and biome class. The dataset comprises over 2 million chunks and tens of billions of tokens spanning 15 biome labels and six human-authored maps, with vocabulary sizes $H \in \mathbb{R}^{D \times R \times A},$1 for the core set and $H \in \mathbb{R}^{D \times R \times A},$2 with human-augmented maps. The paper reports interactive inpainting and outpainting, classifier-free guidance with $H \in \mathbb{R}^{D \times R \times A},$3 and guidance scale 4.0, and evaluation through an adapted render-based FID and a human preference study.

The connection between the two usages is therefore structural rather than methodological. Both operate on cube-like tensors rather than 2D projections, and both argue that preserving native structure improves controllability or fidelity. In CubeDN for radar, the preserved structure is the fused Doppler–Range–Azimuth–Elevation tensor. In Dream-Cubed, it is the native block-token representation of Minecraft worlds. This suggests that "cube-native" modeling has become a recurring design principle across otherwise unrelated domains: 3D sensing on one hand and controllable generative modeling in structured virtual worlds on the other.