K-Radar releases raw 4D radar tensors instead of point clouds

The radar data is a tensor, not a list of detected points

The core claim of the dataset is about the representation of the radar data rather than its volume. K-Radar contains 35K frames of 4D radar tensor data with power measurements along the Doppler, range, azimuth and elevation dimensions, together with carefully annotated 3D bounding box labels of objects on the roads. The README explains what that buys you by contrasting it with the alternatives. Most existing 4D radar datasets provide point cloud formats that deliver a sparse representation after pre-processing of the raw radar tensors, which leads to performance degradation in 3D object detection. Even where tensor format is collected, released datasets include only partial RAED dimensions, two or three dimensions rather than all four. K-Radar and RaDelft are named as the two that provide all four dimensions across the range, azimuth, elevation and Doppler axes, with K-Radar being the largest of the two by scale. The README also gives the reason such datasets are rare, noting that most 4D radar hardware providers restricted external release of raw tensor data due to technology protection and security policies.

The auxiliary sensors exist to make fusion and calibration possible

The dataset does not stop at radar, and the extra modalities are what turn it into a perception benchmark rather than a radar archive. In addition to the tensor, the authors provide auxiliary measurements from carefully calibrated high-resolution Lidars, surround stereo cameras and RTK-GPS. The calibration matters because the detection task needs a common frame, and the README links a video clip showing the 4D radar tensor and the LiDAR point cloud calibration and annotation process, plus another showing the annotation process in the absence of LiDAR point cloud measurements of objects, which is the case where annotation has to come from the radar tensor alone. There is also a video showing each sensor measurement dynamically changing during driving under heavy snow, and one showing the calibration results. The data covers adverse weather including fog, rain and snow across urban roads, suburban roads, alleyways and highways, so the weather condition is a variable in the dataset rather than an accident of when the car was driven.

The repository ships tools, not just data

The repository description is explicit that it provides the K-Radar dataset, an annotation tool for 3D bounding boxes, and a visualization tool for showing inference results and calibrating the sensors. The top level layout shows how those pieces are separated. There are separate entry points for training, testing, labelling, visualisation and evaluation, with main_train_0.py, main_test_0.py, main_labeling.py, main_vis.py, main_fusion_eval_0.py and a pair of files for the conditional pipeline. The supporting directories are datasets/, models/, ops/, pipelines/, configs/, uis/, utils/, tools/ and resources/. The uis/ directory is a separate signal that the labelling and visualisation tools are graphical, and the requirements list backs that up with PyQt5, open3d at 0.15.1, opencv-python and scikit-image. The spconv-cu113 and numba entries in the requirements point at sparse convolution kernels and JIT compilation, which is what a 4D radar detection network needs, and the setuptools pin at 59.5.0 is an old version, which tells you this code was written against a specific PyTorch and CUDA generation.

The data is 15TB, so distribution is the first engineering problem

The dataset documentation states the total data size as 15TB, and the README is upfront that this large size is why there are three delivery routes. Access to the total dataset via a local server, a portion of the dataset via Google Drive, and the total dataset via a shipped hard disk drive. That third option is unusual and worth pausing on. Shipping a hard disk is a real answer to a real problem, the cost of transferring 15TB over a network is prohibitive for many groups, so the maintainers mail physical media and expect the drive back. For a research group that needs the whole set this is likely the only workable route, and for a group that needs a subset, the Google Drive portion is the practical entry point. The dataset preparation guide in docs/ is where the details of each route live, and the README points at it for both the preparation steps and the distribution details. The scale also has a second implication, that every experiment on this data competes for disk, and the storage layout is a decision you make on day one.

The data is non-commercial while the code is Apache licensed

The licensing is split and the split is precise. The K-Radar dataset is published under the CC BY-NC-ND License, and all codes are published under the Apache License 2.0. So you can use the code freely in a commercial product, and the data carries the share-alike, non-commercial and no-derivatives conditions. For a company building a perception stack, the practical reading is that the data itself is not a route to a commercial model, though the annotation and visualisation tools built on top of it are. The technologies have been developed by AVELab at KAIST and are being commercialized by Zeta Mobility, and the README directs commercialization inquiries to that company with a contact address, which suggests a licensing path exists for the data for those who need one. A second practical note is that the repository itself carries no recognised licence in its metadata, so the README statements are what you have to go on, and it is worth asking for the terms in writing if a commercial use depends on them.

The sensor fusion pipeline shows what the data is for

The fusion guide in docs/ describes a pipeline the authors call Availability-aware Sensor Fusion, and the reason to read it is that it demonstrates the intended use of the dataset. The claim is sensor availability awareness, maintaining performance even when sensors fail or degrade in adverse conditions by automatically prioritising the available ones, and the visualisations use sensor attention maps where red, green and blue represent attention scores for camera, LiDAR and 4D radar, with predominantly blue maps in adverse weather indicating that 4D radar received the highest attention. That is the argument the dataset is built to support, that radar can carry detection when the optical sensors are blind. The stated figures are 87.4% AP3D at IoU 0.3 and 73.6% AP3D at IoU 0.5 including challenging weather, with memory usage of 1.5 to 1.6GB and processing speeds of 13.5 to 20.5Hz. The detection and tracking guide in docs/ covers the radar-only pipeline, and the tracking video shows the information on tracking for multiple objects.

Where K-Radar is the wrong choice

Three situations argue against it. The first is a team without 15TB of storage and a way to move it. The dataset is one of the largest of its kind, the download route is a shipped hard disk, and a lab that cannot absorb that cost will end up working with the Google Drive portion, which by definition is not the whole thing, and then any result you claim is a result on a subset. The second is a commercial perception team, because the data is CC BY-NC-ND and the commercialization path runs through a separate company rather than through a self-service licence. The third is a project that needs camera or LiDAR data rather than radar, since the auxiliary modalities exist to support radar fusion and calibration, and if the radar tensor is not your interest then a camera or LiDAR-centric dataset is the cheaper and more direct path. There is also a maintenance signal worth reading. The repository is not archived, but the last push was on 2026-06-26 and the project publishes no GitHub releases, so the code and the pinned dependency set reflect a particular moment rather than a continuously released tool, and the old setuptools and cu113 pins mean the environment is defined by the authors' machine rather than by current practice.

Editorial conclusion

Adopt K-Radar when you are training or evaluating a 4D radar object detector and need the unprocessed tensor rather than a sparse point cloud, and use a smaller curated radar dataset if you need to iterate quickly. Verify first which distribution route you will use, because the full dataset is 15TB and arrives either from a local server, a Google Drive portion or a shipped hard disk. Read the dataset preparation guide in docs/ before installing anything, since the tensor format and the calibration artefacts are what the code expects.

Frequently asked questions

Official sources

1. Issues
2. kaist-avelab/K-Radar on GitHub
3. README