mmWave radar

mmWave radar – definition

Millimetre-wave (mmWave) radar is an active radio-frequency sensing method that estimates the range, relative radial velocity, and direction of objects from reflected electromagnetic waves. The term commonly covers frequencies from 30 GHz to 300 GHz, corresponding to wavelengths from 10 mm to 1 mm. In mobile robotics, practical mmWave radar sensors often operate in the 60 GHz or 76-81 GHz bands, depending on the device, region, and intended application.

For an unmanned ground vehicle (UGV), mmWave radar provides perception data that is relatively insensitive to darkness, direct sunlight, dust, fog, light rain, and some visually challenging surfaces. It does not replace LiDAR, depth cameras, or wheel odometry. Instead, it adds measurements that are especially useful for detecting moving objects and estimating their radial velocity.

Most compact robotics radars use frequency-modulated continuous-wave (FMCW) operation. An FMCW radar transmits a frequency chirp, receives its reflection, and processes the frequency difference between transmitted and received signals. The resulting radar detections can be represented as range-Doppler measurements, point clouds, tracked objects, or occupancy evidence.

Source: International Telecommunication Union, ITU-R Recommendation V.431; Texas Instruments, Introduction to mmWave Sensing: FMCW Radars.

How FMCW mmWave radar measures range and velocity

An FMCW radar transmits a chirp whose frequency changes linearly over time. A reflection from an object arrives with a time delay. After mixing the transmitted and received signals, the radar obtains a beat frequency that is related to target distance.

For a simplified linear chirp and a stationary target, the target range can be approximated as:

R = (c × f_b) / (2 × S)

Where R is range, c is the speed of light, f_b is beat frequency, and S is chirp slope in Hz/s. Range resolution depends primarily on transmitted bandwidth:

ΔR = c / (2 × B)

Where ΔR is range resolution and B is chirp bandwidth. A larger bandwidth produces finer range resolution. Doppler processing across repeated chirps estimates radial velocity. The radial component is important: a target moving sideways relative to the radar can have a low measured Doppler velocity even when its true ground velocity is high.

Angle estimation is normally based on phase differences between multiple receive antennas or virtual antenna elements. MIMO radar processing can create a larger virtual antenna array by combining multiple transmit and receive antennas. The resulting angular accuracy depends on antenna geometry, signal-to-noise ratio, calibration, processing configuration, and environmental multipath.

Key mmWave radar outputs for UGV perception

Radar firmware and host-side processing determine which data is available to ROS 2. Some sensors publish raw ADC samples, while others publish processed detections or object tracks. The following outputs are common in mobile robotics integrations.

Output	Typical content	UGV use
Radar point cloud	Position, Doppler velocity, intensity or signal-to-noise ratio	Obstacle detection and sensor fusion
Range-Doppler map	Signal energy indexed by distance and radial velocity	Research, tracking, clutter analysis
Object tracks	Filtered target position, velocity, track identifier	Dynamic obstacle monitoring
Static occupancy evidence	Stationary radar returns or occupancy-grid evidence	Local costmaps and terrain-aware perception

Radar point clouds are not equivalent to LiDAR point clouds. Radar detections are usually sparser, have wider angular uncertainty, and can include multipath reflections. Radar reflectivity also depends on material, shape, incidence angle, polarization, and target motion.

mmWave radar integration in ROS 2

ROS 2 does not define one mandatory radar message type comparable to the broadly used sensor_msgs/msg/LaserScan interface for 2D laser scanners. Drivers therefore commonly publish sensor_msgs/msg/PointCloud2, sensor_msgs/msg/Imu for integrated inertial data, or vendor-specific messages. The ROS package radar_msgs provides radar-oriented message definitions, but its use is not universal across hardware vendors.

A robust ROS 2 integration should publish each radar measurement with a correct timestamp and coordinate frame. The radar frame should be connected to base_link through tf2. REP 103 defines ROS coordinate conventions, including x forward, y left, and z up for body frames. REP 105 defines commonly used mobile-robot frames such as map, odom, and base_link.

radar_driver:
  ros__parameters:
    frame_id: radar_link
    publish_pointcloud: true
    pointcloud_topic: /radar/points
    use_sensor_time: true

The static transform must reflect the measured sensor position and orientation on the UGV. A small yaw error can shift detections laterally at longer ranges and reduce the quality of camera, LiDAR, or map fusion.

Sources: REP 103; REP 105; ROS 2 sensor_msgs documentation.

Use with Leo Rover and Raph Rover

On Leo Rover, mmWave radar is an optional perception payload. Leo Rover uses a differential-drive base and can be used with ROS 2 through compatible software packages. It is not autonomous out of the box. A radar integration therefore requires a compatible driver, power and mounting design, a calibrated radar_link transform, and a navigation or perception stack configured for the intended environment.

For a Leo Rover operating indoors or on structured outdoor routes, radar can complement a 2D LiDAR or depth camera by identifying moving returns in low-light conditions. The onboard Raspberry Pi is suitable for lightweight driver operation and basic point-cloud handling, but computationally intensive radar processing, multi-sensor tracking, or neural perception pipelines may require an external compute unit.

Raph Rover is more suitable where the radar payload requires greater mounting volume, electrical capacity, or additional compute hardware. Its larger payload capability can support combined radar, LiDAR, GNSS/RTK, and camera configurations for inspection, agriculture, construction-site monitoring, or research deployments. The radar should not be used as the only source for close-range collision avoidance without validation of minimum range, field of view, update rate, and false-detection behaviour for the selected sensor.

Limitations and validation

Radar performance must be validated in the actual operating environment. Metal fences, building facades, wet ground, vegetation, and narrow corridors can create multipath reflections. Stationary objects may be suppressed by firmware designed for automotive use. Conversely, rotating wheels, vegetation, or rain can create detections that need filtering.

Before using radar data in a local costmap, record ROS 2 bags and evaluate detection probability, false alarms, latency, frame alignment, and behaviour at the platform’s maximum operating speed. Safety-related stop logic requires a sensor and system architecture designed and validated for the applicable safety requirements; general-purpose radar data alone is not sufficient. Parameters must be taken from the selected radar manufacturer’s datasheet and firmware documentation, because range, update rate, field of view, and point-cloud format are configuration-dependent.