Configurable mmWave Safety Sensor System for Omnidirectional Short-Range Obstacle Detection on Maritime Vehicles

1. Problem, Motivation & Context

Maritime vehicles rely on multiple sensors for navigation and situational awareness, yet a dedicated short-range proximity safety layer is required to reliably detect obstacles in the vessel's immediate surroundings and support collision avoidance. This project investigates a configurable millimetre-wave (mmWave) sensing system for this role.

1.1 Problem Gap

LiDAR has been explored for maritime perception, but close-range operation can be affected by wave splash, spray and other maritime clutter. On the ST Engineering platform motivating this project, LiDAR is used primarily for target tracking at range rather than as a dedicated close-range safety sensor. The project therefore investigates whether mmWave radar can provide a more robust short-range proximity sensing layer while retaining useful spatial and velocity information.

1.2 Project Value

The intended contribution is not only a radar installation, but a configurable sensing architecture that can be adapted to vessels of different geometries and sensor counts. The project combines sensor technology evaluation, configurable multi-sensor integration, point-cloud processing, proximity alarming, visualisation, and maritime validation against LiDAR/camera reference data.

2. Objectives & Scope

The project aims to evaluate candidate technologies for short-range omnidirectional proximity detection on maritime vehicles, select a suitable sensing technology using defined performance criteria, and deliver a functional multi-sensor prototype benchmarked against a LiDAR reference under maritime operating conditions.

The project scope covers: (1) sensor technology survey and selection; (2) single-sensor characterisation; (3) configurable multi-sensor integration and software; (4) real-time visualisation; (5) sea trials; (6) coverage and sensor-placement evaluation; and (7) benchmarking against LiDAR/camera ground truth.

2.1 System Requirements

• Short-range obstacle detection around the vessel with a configurable safety standoff distance R.
• Support for multiple radar sensors mounted at configurable 6-DOF poses.
• Transformation of all sensor detections into a common vessel body coordinate frame.
• Real-time ingestion of 4D radar point clouds containing spatial position and radial velocity.
• Configurable clutter rejection and temporal confirmation parameters.
• Real-time vessel-centric visualisation for operation and diagnostics.
• Architecture scalable to N sensors; the FYP hardware prototype will validate up to two sensors due to project time and procurement constraints.

2.2 Evaluation Metrics

• Detection rate: proportion of real obstacles within the safety region that are successfully detected.
• False alarm rate: frequency of alarms caused by maritime clutter rather than genuine obstacles.
• Angular coverage: completeness of the required vessel safety envelope and identification of blind sectors.
• Latency: delay between an obstacle becoming detectable and a confirmed proximity alarm.
• Sensor-level metrics: range, angular accuracy, update rate and point-cloud characteristics.

3. Sensor Technology Selection

Candidate technologies are evaluated against maritime-specific requirements including detection performance, susceptibility to clutter, field of view, update rate, weather robustness, deployability, data interface, ruggedness and cost. Candidate classes include short/medium-range mmWave FMCW radar, purpose-built marine radar and other applicable proximity sensing technologies.

The technology trade study is intended to justify the selected sensing modality and hardware rather than assuming mmWave radar is optimal from the outset.

3.1 Selected Radar: CTLRR-540 4D Imaging Radar

The currently sourced sensor is the CTLRR-540, a 76–79 GHz FMCW 4D imaging radar. Vendor specifications state a 0.2–360 m range, up to 2048 point-cloud returns per frame, 50 ms data period, ±60° azimuth field of view, ±15° elevation field of view, 12 V operation, ≤10 W power consumption, Ethernet/CAN interfaces, and IP6K7/IP6K9K environmental protection.

For this project, the Ethernet output is required because the vendor has indicated that the full 4D point-cloud output, including elevation/Z information, is available through automotive Ethernet whereas the CAN output does not provide the required Z information. Integration therefore uses an automotive-Ethernet-to-standard-Ethernet media converter before connection to the onboard computer network.

4. System Concept & Methodology

The system separates the sensor transport layer, radar-message decoding, point-cloud processing and vessel-level safety logic. This modular design allows recorded or synthetic data to support software development before the physical radar is integrated. Simulated data will test software behaviour and configuration logic; it will not be treated as evidence of real radar detection performance.

4.1 Detection and Object Characterization Pipeline

The CTLRR-540 vendor protocol defines two relevant outputs: 0x11 RAW_TARGET_DATA, representing post-DSP detection points before vendor tracking, and 0x21 TRACK_TARGET_DATA, representing vendor-tracked objects. The project intends to decode both streams if they are enabled in the supplied firmware. These are processed radar outputs, not raw ADC/IQ samples. Actual message availability and decoded field meanings will be verified against live packets.

For point-level processing, range and angles are converted to Cartesian coordinates according to the vendor coordinate convention, after validating axes, signs, units and angle definitions. DBSCAN and radial velocity are candidate processing features, not presumed improvements. Cluster extent is reported as radar-visible extent rather than guaranteed physical object dimensions. Size is treated as one candidate feature, not an unconditional reason to reject a potentially hazardous small obstacle.

Temporal association creates persistent object identifiers and measures track continuity. The system then evaluates whether a confirmed obstacle intersects a configurable warning region R. Operational warning distance must ultimately be justified from vessel speed, response delay, stopping/avoidance capability and margin; it is not yet a validated safety threshold.

4.2 Configurable Multi-Sensor Architecture

Each radar is represented as a sensor node with a deployment configuration containing a unique sensor identity and a six-degree-of-freedom pose relative to the vessel body frame. A rigid-body transform maps each sensor's detections into the common vessel frame, after which the system can associate overlapping detections and tracks. The processing stack is designed for a configurable number of nodes, while the practical FYP target is integration of up to two radars.

Configurability means changing sensor count, calibrated pose, warning distance and processing parameters through configuration rather than rewriting the detection pipeline. Coverage claims will account for mounting height, pitch, hull occlusion and the difference between nominal field of view and measured detection capability. Each CTLRR-540 has a nominal ±60° horizontal FOV; two such units do not by themselves guarantee 360° coverage. Larger sensor configurations will be assessed geometrically/synthetically, while physical validation will be limited by available hardware and time.

4.3 Communications Architecture

The proposed data path converts the radar's two-wire automotive Ethernet interface to standard RJ45 Ethernet, then connects each radar node through an Ethernet switch to the Jetson AGX Xavier. The CTLRR-540 manual identifies the differential Ethernet pins as ETH_M and ETH_P and specifies a 100 Mbps Ethernet interface. The supplied LD-100BASE-T1 converter is described by the vendor as an automotive-Ethernet-to-RJ45 physical-layer converter. Final PHY compatibility, master/slave setting and harness pinout should be confirmed against the supplied hardware.

The vendor supplied a Python UDP receiver and a protocol matrix defining 0x11 RAW_TARGET_DATA (post-DSP detection points) and 0x21 TRACK_TARGET_DATA (tracked objects). The intended implementation reuses a standard Linux Ethernet NIC and socket stack, then develops a user-space packet decoder and frame assembler; a custom Linux kernel Ethernet driver is not expected for this standard RJ45 link.

The example receiver uses UDP port 51277 and multicast group 224.0.2.6. These settings must be checked against the radar's actual configuration and packets. Two radars should have unique network identities where possible; identical factory IPs cannot be assumed to work on the same ordinary LAN merely by assigning multiple IP addresses to the host. Timestamp semantics, packet loss handling, point-field units/axis conventions, and simultaneous stream output will be validated during integration.

4.4 Power System Architecture

The power design separates the radar supply, media converters, Ethernet switch and host computer into protected branches. The final vessel supply design depends on the available DC bus and the exact Xavier developer/carrier board; bench testing will use the correct Xavier power adapter and a current-limited radar supply until the integrated supply budget is verified.

Each CTLRR-540 is specified at 12 V and no more than 10 W. Therefore, the two-radar load is at most 20 W (about 1.67 A at 12 V), before engineering margin. The LD-100BASE-T1 converter label states DC 9–36 V or USB 5 V input; its current draw must be confirmed. The Ethernet switch supply and the exact AGX Xavier board power input must be matched to their respective specifications. Do not assume the radar's 12 V rail can power every component directly.

4.5 Vessel-Centric 3D Visualisation

The operator/diagnostic interface will present the vessel at the origin of a three-dimensional scene together with radar poses and fields of view, raw/fused point clouds, detected clusters and bounding boxes, proximity zones and alarm state. The interface is intended to make sensor placement, coverage, blind sectors and detections observable during simulation and sea trials.

5. Interim Development & Validation

The Semester 1 interim work prioritises a controlled LiDAR baseline characterization of temporary target-visibility loss under water spray. This establishes a repeatable, instrument-specific benchmark for later comparison with the CTLRR-540. The radar's procurement lead time means physical radar results are not assumed for the interim assessment. Experimental findings will be reported only after data collection and analysis.

5.1 Controlled LiDAR Water-Spray Characterization

Research question: How does a repeatable water-spray disturbance crossing the LiDAR-to-target optical path affect fresh target measurements, the duration of detection loss and recovery after spray cessation?

Apparatus: Livox Mid-360 LiDAR on a fixed mount; Insta360 X4 camera for scene documentation and spray-event annotation; a stationary, measured solid target approximately 3–5 m from the LiDAR; a controlled shower or nozzle directed into a collection vessel; and a computer recording timestamped point-cloud data. The target distance, sensor height, spray position, target dimensions and acquisition settings will be documented. Wet testing requires a suitable location, safe power isolation and water containment.

Protocol: Each target-present trial comprises approximately 10 s of unobstructed baseline, 10 s with spray crossing the line of sight, and 20 s after spray stops. The intended pilot uses 5–10 repeated trials per condition where feasible. Separate target-absent control recordings will distinguish spray/background returns from true target returns. Spray start and stop will be annotated using synchronized video or a recorded timing cue.

Spray characterization: Collected water volume V, horizontal collection area A and collection time t give an equivalent precipitation rate I = V/(A t), reported in mm/h after unit conversion. This is a repeatability descriptor; it does not imply that a shower reproduces natural rainfall droplet distributions or vessel-generated sea spray.

Offline processing: Record the complete timestamped LiDAR point-cloud stream first, then replay it for analysis. A fixed three-dimensional target region of interest (ROI) is defined from the measured target location and dry baseline. A separate spray ROI describes the disturbed optical path; bucket walls, floor and other fixed background geometry are excluded. Points are grouped into fixed-duration observation windows. The same predeclared target-return rule is applied to dry, spray and recovery windows, without relying on tracker-predicted positions.

5.2 Quantitative Baseline Metrics

• Target measurement availability: A = N_visible / N_eligible × 100%, where a visible window satisfies a fixed target-associated return criterion. Report dry and spray intervals separately; this is not automatically object-detector accuracy.
• Continuous measurement-loss duration: T_loss,i = t_end,i − t_start,i for each consecutive run of unavailable target measurements. Report maximum duration, distribution and event count.
• Post-spray recovery time: T_recovery = t_{stable reacquisition} − t_{spray off}. Stable reacquisition requires a fixed number of consecutive visible windows; report zero if visibility never ceased, and censor trials without reacquisition during observation.
• Target-region point retention: P_retention = mean(N_ROI,spray) / mean(N_ROI,dry) × 100%. Because spray returns may enter the target ROI, this is a proxy for visibility, not a guaranteed count of genuine target reflections.

Secondary measurements: point counts in the empty-space spray ROI, target range error when valid target returns are available, and false obstacle-warning events if a separately specified and fixed detection algorithm is evaluated. Measurement loss, object detection failure and tracker prediction will be reported as distinct phenomena.

Interpretation and limitations: This laboratory study isolates an optical-path disturbance rather than reproducing full maritime sea states, vessel motion or window wetting. It characterizes the particular LiDAR configuration used and does not establish that all LiDAR technologies fail. Subsequent radar testing will repeat equivalent controlled scenarios and use independent target ground truth.

5.3 Supporting Software Development

In parallel, the planned Linux/ROS 2 architecture will accept replayed or synthetic point-cloud data through a common interface. This supports early development of detection, object-level output and visualization without treating synthetic data as experimental evidence of radar performance. The CTLRR-540 Ethernet protocol defines detection-point and vendor-track streams; their physical integration and measured performance remain subjects of Semester 2 validation.

5.4 Hypotheses for Experimental Evaluation

• H1: Temporal persistence filtering reduces false alarms from transient clutter, with a corresponding increase in detection latency as K increases.
• H2: Incorporating radial velocity into the processing pipeline can improve discrimination between genuine obstacles and maritime clutter compared with spatial information alone.
• H3: Minimum physical-size filtering can reduce false alarms without materially degrading detection of objects satisfying the operational minimum threat-size criterion.
• H4: Configurable multi-radar placement can achieve the required angular coverage while managing overlap, blind sectors, cost and potential inter-radar interference.

6. Experimental Validation Plan

After hardware arrival, controlled single-radar tests will characterise range, angular performance, point-cloud density, update rate, data interface behaviour and the contribution of Doppler information. The radar will subsequently be deployed on the NUS Bumblebee Autonomous Systems BlueBoat platform. Existing LiDAR and camera sensing will provide reference information for evaluating detection rate, false alarm rate, latency and angular coverage under maritime conditions.

Two-radar testing will then evaluate coordinate-frame fusion, overlap handling, placement trade-offs and any practical effects of simultaneous radar operation. The final system will be benchmarked against the LiDAR reference with particular emphasis on false alarms caused by maritime clutter.