LiDAR–RADAR Sensor Fusion and Telemetry Data Integration for Obstacle Detection Along the UAS Navigation Trajectory

Abstract

Today, the use of UASs (unmanned aerial systems) is rapidly expanding across civil, military, and scientific applications. The deployment of drones in close proximity to urban areas is becoming increasingly common, particularly during missions conducted beyond visual line of sight (BVLOS) or in fully autonomous modes. Advancements in technology have enabled the development of systems and platforms that no longer require a human operator onboard and are equipped with progressively higher levels of autonomy. Therefore, enhancing onboard systems is crucial to ensure a high level of operational safety, particularly during missions conducted in harsh and complex environments, such as urban and suburban areas, where the presence of a large number of static and dynamic obstacles, including pedestrians, vehicles, and other aircraft, is pervasive. In this context, the implementation and integration of multiple onboard devices and sensors represent the core focus of this work, with the objective of improving perception, navigation, and safety capabilities for autonomous UAV operations. In particular, communication channels, hardware integration, and data fusion techniques have been implemented and evaluated to improve system performance and situational awareness. This work presents the hardware and software integration of LiDAR and radar sensors with a Pixhawk autopilot and a Raspberry Pi companion computer, aimed at developing obstacle detection applications.

1. Introduction

The use of UASs have increased significantly in recent years, with operations in urban environments for applications such as surveillance, delivery services, and urban and industrial monitoring. This trend has led to the development of the concept of urban air mobility (UAM) for the transport of passengers and packages using UAS [1,2,3]. To ensure the safety, automation, accessibility, and cost-effectiveness of these services, a series of laws and regulations and new technologies need to be developed [4,5].

A key technology for an agile and safe integration of UAS operations is detect and avoid (DAA) systems, which enable UAVs to detect both fixed and mobile obstacles, such as buildings and other aircraft, and to model the surrounding flight environment, thereby avoiding any type of obstacle by instructing the autopilot to perform evasive maneuvers with high precision. The implementation of DAA capability involves three key components that ensure safe and efficient operation [6,7]:

• Perception: The ability to use environmental data to generate accurate models of the flight environment in order to identify potential risks;
• Trajectory planning: The ability to generate flight trajectories that enable obstacles to be avoided, while maintaining safe and efficient navigation;
• Flight control: The ability to generate commands to perform evasive maneuvers that are capable of avoiding fixed and moving obstacles.

Controlling UAS, whether autonomously or remotely piloted, requires constant awareness of the aircraft’s status in terms of position, attitude, and speed, thanks to integrated IMU platforms onboard. In a DAA system, this information must be integrated with data from other onboard sensors such as radar [8], LiDAR [9], GNSS-INS [10,11], and RGB-D cameras [12,13]. Recent research has explored sensor fusion strategies, such as LiDAR combined with IMU [14,15,16,17], LiDAR with cameras [18,19,20,21], or radar with LiDAR [22,23,24,25,26,27], to increase robustness in obstacle detection.

Without a pilot onboard, UASs rely heavily on DAA systems to ensure safe operations, especially during missions performed in BVLOS modality [28,29,30,31,32,33].

By integrating obstacle detection sensors with telemetry data acquired by IMU platforms, vehicles in urban environments can dynamically modify their trajectory, taking into account structural, environmental, and regulatory limitations.

There exist research studies investigating sensor fusion between LiDAR and radar (or other complementary sensors) for obstacle detection in autonomous vehicles and UAVs. LiDAR and radar are often used in combination to compensate for the limitations of individual sensors and to improve robustness and accuracy. However, in the literature that is specifically focused on UAVs, the number of published works that directly integrate both LiDAR and radar technologies remains relatively limited compared to LiDAR–camera or radar–camera fusion approaches. In [34], LiDAR–radar depth data fusion was employed to enhance environmental perception for intelligent and connected vehicles (ICVs). In [22], a LiDAR–radar sensor fusion approach aiming to improve obstacle detection by exploiting the complementary advantages of the two sensors was implemented using a global nearest neighbor (GNN) filter for automotive applications. Similarly, Ref. [35] investigated LiDAR–radar fusion for robust perception under adverse weather conditions, such as fog.

LiDAR–radar fusion offers significant benefits for perception in autonomous systems, particularly in UAV and automotive applications. LiDAR provides accurate three-dimensional spatial measurements, while radar contributes direct velocity estimation and maintains reliable performance under adverse environmental conditions, such as rain or low visibility. By combining these complementary modalities, sensor fusion reduces false positives, enhances robustness in complex scenarios, and enables effective detection and avoidance of moving obstacles through detailed spatial mapping and dynamic tracking. However, implementing such systems presents several practical challenges. High-power radar and 3D LiDAR sensors increase weight and power consumption, limiting UAV endurance. Accurate temporal and spatial calibration between sensors adds implementation complexity, while the fusion process demands substantial computational resources, often beyond the capabilities of standard UAV microcontrollers. Moreover, integrating heterogeneous data types, such as LiDAR point clouds and radar returns, requires sophisticated algorithms, including advanced filtering techniques or neural network-based approaches, to ensure reliable perception. Despite these challenges, LiDAR–radar fusion remains a promising approach to improve both robustness and accuracy in obstacle detection under a wide range of operational conditions.

This work describes the hardware and software integration of LiDAR and radar sensors with a Pixhawk autopilot and a companion computer, Raspberry Pi, aiming to develop obstacle detection applications for the safety trajectory. The complete system is designed to manage the data flow, including LiDAR–radar data fusion, for obstacle detection. The fused data can provide alerts or warnings to the operator in the presence of nearby obstacles while being integrated with navigation and attitude information from the flight controller, enabling a comprehensive perception and monitoring capability for UAV operations.

The software modules, implemented in Python 3.9 and Matlab R2024b environments, enable the acquisition of telemetry data from the flight controller and the processing of obstacle detection data provided by the LiDAR and radar sensors. To assess the reliability of communication among the different components, a series of experimental tests were conducted in both real and controlled environments. This approach will enable the future development of an obstacle detection and avoidance (DAA) algorithm, based on the integration of navigation data received from the autopilot with obstacle detection data collected by the sensors.

The paper is organized as follows: Section 2 presents the materials and methods involved and Section 3 details the work and obtained results. Finally, Section 4 concludes the paper with final considerations and potential directions for future work.

2. Materials and Methods

This section provides a description of the hardware employed for the system developed as part of an obstacle detection system for UAM operations. The architecture is composed of several key components, including a flight control board (FCB), Pixhawk 2.4.8 (Radiolink, Shenzhen, China), a companion computer, Raspberry Pi 5 (Raspberry Pi, Cambridge, UK), and two sensors used for obstacle detection (LiDAR and radar). The interfacing methods and communication protocols between the different modules are as follows:

• Pixhawk 2.4.8–Raspberry Pi 5: Communication via MAVLink protocol using UART serial port [36].
• Radar-On-Chip IWR 1642–Raspberry Pi 5: Communication via the TI mmWave SDK proprietary protocol using UART serial port.
• 3D LiDAR Helios 16P–Raspberry Pi 5: Communication via UPD protocol using Ethernet port.

This interface facilitates the seamless exchange of data between the autopilot, radar and LiDAR sensors and the computational platform, enabling the real-time processing of sensor inputs and control commands that are essential for the obstacle detection system’s functionality.

2.1. Experimental Platform

An experimental platform, consisting of the following components, was created to simulate a drone (Figure 1):

• Flight control board (FCB): Pixhawk 2.4.8;
• GPS receiver: Radiolink MN10 SE100;
• Radio modem: FPV Radio Telemetry;
• Li-Po battery: Turnigy 4.0;
• Power module: APM Power Module GM v1.0.

This platform allows for testing and validation of the communication interface and obstacle detection algorithms in a real controlled environment.

2.1.1. Flight Control Board Pixhawk 2.4.8

The FCB Pixhawk 2.4.8 (Figure 2) is an open-source controller based on a project developed by 3DRobotics that is highly used for unmanned vehicle applications. It operates on the NuttX Real-Time Operating System (RTOS), ensuring efficient and reliable task execution.

Pixhawk 2.4.8 is powered by a 32-bit STM32F427 Cortex-M4 CPU with an integrated FPU and 128 KB of RAM, which provide enhanced real-time data processing capabilities. The integrated IMU is composed of a barometer and 3-axis gyroscope, accelerometer and magnetometer. The controller also offers eight RC channels and several serial ports (UART, I²C, SPI, CAN), enabling versatile communication with external devices [37].

This autopilot is an integral component in modern UAVs that is designed to support precise navigation and reliable data acquisition. Its versatile architecture enables seamless integration with external sensors, ensuring accurate environmental awareness and robust autonomous flight capabilities.

2.1.2. GPS Receiver: Radiolink MN10 SE100

Although Pixhawk autopilot already has an integrated GPS receiver, an external module has been used in the adopted configuration. The selected one is the Radiolink MN10 SE100 (Figure 3), a module equipped with an integrated magnetometer, which supports both GPS and GLONASS satellite systems, offering extended satellite coverage and highly accurate positioning capabilities, which improve the stability and navigation of the aircraft [38]. The main specifications are summarized in

Table 1. Radiolink MN10 SE100 specifications [38].

Positional Accuracy	50 cm with Concurrent GNSS 2.5 m with Single GNSS
Velocity Precision	0.1 m/s
Max Height	50,000 m
Max Speed	515 m/s
Max Acceleration	4 G
Max Update Rate	Up to 15 Hz
Connect Ports	UART
Power Supply	V: 3.3 VDC ± 5% I: 50~55 mA

.

2.1.3. Radio Telemetry System

The FPV Radio Telemetry system (Figure 4) is an open-source communication platform which offers an efficient and straightforward solution for monitoring and controlling UAV operations. It is composed of due modules operating at a rated frequency of 915 MHz:

• Air module: Installed onboard the vehicle, connected to the Pixhawk’s “TELEM1” port;
• Ground: Connected via a USB connector to the ground control station (GCS) laptop.

Key features of radio telemetry include:

• Long-range communication: Provides reliable data transmission between UAV and GCS;
• Bidirectional datalink: Supports two-way communication for real-time telemetry data and commands from ground station;
• Low latency: Ensures fast data exchange for navigation, monitoring, and control;
• Compact and lightweight: Minimizes impact on UAV payload capacity;
• Wide compatibility: Works with most used ground control software, such as Mission Planner or QGroundControl, and flight controllers, such as Pixhawk.

2.1.4. Li-Po Battery Turnigy 4.0

The battery used to power the experimental platform is a Turnigy 4.0 4000 mAh LiPo battery, which is widely used in radio-controlled models. The choice of LiPo batteries is due to their lower weight and volume compared to other types of batteries, as well as their ability to provide high specific energy, which makes them perfect for use in applications where weight is a key design feature.

The Turnigy 4.0 consists of four cells in series configuration, with a standard nominal voltage of 14.8 V [39]. The voltage and weight of LiPo batteries are closely related, making it necessary to compromise between the two when choosing the right battery (Figure 5).

In

Table 2. Turnigy 4.0 specifications [39].

Capacity	4000 mAh
Configuration	4S1P/14.8 V/4 cells
Constant discharge	30 C
Discharge peak	40 C
Size and weight	148 × 50 × 29 mm 452 g

, its main characteristics are highlighted.

2.1.5. Power Module

A power module is used to correctly monitor the essential energy parameters (voltage, current, and total energy consumption) of an autonomous vehicle, and to efficiently manage the system’s power supply while providing accurate energy consumption data.

In this case, the APM Power Module GM v1.0 has been used, Figure 6. This module includes a current sensor that can handle up to 90 A, making it suitable for medium- and high-power autonomous aircraft. In addition, the module includes a voltage regulator that provides a stable 5.3 V output to power the FCB. It is used to measure the vehicle’s energy consumption in real time and to prevent overloading or battery depletion during flight.

2.2. Radar Sensor

The radar sensor used is IWR1642 Radar-On-Chip, developed by Texas Instruments (Dallas, TX, USA), an advanced platform for real-time detection and tracking applications. Built on frequency modulated continuous wave (FMCW) radar technology (Figure 7), it operates within the 77 GHz to 81 GHz frequency range, with a chirp bandwidth of up to 4 GHz. This architecture enables efficient radar signal analysis, ensuring high performance in object detection and motion estimation.

Combining a compact design, low power consumption, and embedded processing capabilities, the IWR1642 module is particularly suitable for applications in autonomous mobility, robotics, and environmental perception systems, where reliable detection and fast processing are essential [40].

The IWR1642 features a monolithic implementation of a multiple-input, multiple-output (MIMO) (2TX, 4RX) system and integrates a DSP subsystem (C674x) for radar signal processing. Additionally, the device includes an ARM R4F-based processor subsystem, responsible for front-end configuration, control, and calibration. The sensor architecture allows for flexible programming, enabling various sensor implementations through dynamic reconfiguration, which supports multimode operation. In

Table 3. IWR 1642 characteristics [40].

Range	Up to 84 m
Range resolution	37 cm
Max target speed	29.33 km/h
Speed resolution	0.46 km/h
Antenna FoV	±60 deg
Working frequency	77 to 81 GHz
Operating temperature	From −40 °C to +85 °C

the main characteristics are shown.

2.3. LiDAR Sensor

The 3D LiDAR Helios-16P sensor (Figure 8), developed by RoboSense/Shenzhen Suteng Innovation Technology Co., Ltd. (Shenzhen, China), is a solid-state hybrid LiDAR system that integrates 16 laser/detector pairs within a compact housing. Originally conceived for the automotive industry, it has also been widely adopted in robotics and autonomous systems. With its compact architecture and ability to generate high-density point clouds (288,000 points/s), the device enables accurate three-dimensional reconstruction of the surrounding environment, that is not used in our use case (UAM obstacle detection), since our objective is to measure distances.

The 16 laser beams provide a 360 degree angular coverage in the plane, perpendicular to the cylinder axis (horizontal plane) with 0.2 degree steps and a horizontal resolution of 0.1 degrees. In the vertical plane, the field of view (FOV) spans 30°, ranging from −15° to +15°, with angular resolution of 2°, resulting in 16 discrete scanning levels. The sensor has a typical power consumption of 11 W.

The 3D LiDAR Helios-16P has a weight of 0.9 kg with a diameter of 97.5 mm and a height of 100 mm, operating at a single wavelength of 905 nm [41].

The integration of optical components and processing capabilities within a single module makes the sensor particularly suitable for scenarios where reliability, robustness, and continuous data acquisition are essential.

Table 4. 3D LiDAR Helios 16P characteristics [41].

Number of Channels	16
Wavelength	905 mm
Measurement range	0.2–150 m
Measurement accuracy	1 cm (1σ)/3 cm (3σ)
Horizontal FOV	360°
Vertical FOV	30° (from −15° to +15°)
Frame rate	10 Hz/20 Hz
Operating temperature	From −40 °C to +60 °C

shows the operation characteristics of the sensor.

2.4. Companion Computer

The system employs a Raspberry Pi 5 (Figure 9), a single-board companion computer developed by the Raspberry Pi Foundation and originally designed for programming, education, and prototyping activities. Within UAS platforms, this type of computer is integrated to enhance the onboard computational capabilities. Due to its versatility, the Raspberry Pi 5 is widely adopted in various application domains, such as the Internet of Things (IoT), the Internet of Drones (IoD), robotics, and home automation.

The device is equipped with a quad-core ARM Cortex-A76 processor running at 2.4 GHz. For peripheral interfacing, it provides 40 GPIO pins, two USB 3.0 ports, and two USB 2.0 ports, along with a PCIe 2.0 x1 connector for high-speed expansion. Power is supplied through a USB-C connector at 5 V/5 A, compliant with USB power delivery. The operating system used on this Raspberry Pi 5 is Linux Debian 12 (kernel 6.x). The version employed includes 16 GB of LPDDR4X-4267 RAM, ensuring high performance for memory-intensive applications [42].

3. Simulation and Results

This section presents the results obtained during the validation tests of the integrated obstacle detection system. It outlines the procedures for connecting and configuring the sensors, including the processing of raw data and the application of corrections to ensure an accurate representation of the surrounding environment. Furthermore, the software architecture enabling real-time data synchronization, transmission, and final visualization through the graphical user interface (GUI) is described.

3.1. Pixhawk–Raspberry Pi Connection

The connection between the autopilot Pixhawk 2.4.8 and the companion computer Raspberry Pi 5 (Figure 10) is established through the TELEM 2 port on the Pixhawk and the GPIO pins of the Raspberry Pi, using a UART serial connection. Specifically, the cabling is made as follows, as described in detail in [36]:

• Pin 6 → GND (ground reference);
• Pin 8 → TX-RX (data transmitted by Raspberry Pi);
• Pin 10 → RX-TX (data transmitted by Pixhawk).

This interface is designed to transmit telemetry data generated by the flight control board to the companion computer, enabling the data to be processed and integrated with information from additional sensors within the overall system architecture.

For the data acquisition, the open-source Python 3.9 package MAVProxy was utilized, leveraging the MAVLink communication protocol. This allowed for the management of a wide range of telemetry data, including attitude, position, and velocity [36,43]. Only three data packages were selected, as they are essential for obstacle detection applications. The selected packages are:

• ATTITUDE;
• GLOBAL_POSITION_INT;
• VFR_HUD.

Table 5. Data navigation acquired.

Package	Data	Unit
ATTITUDE	roll	deg
	pitch	deg
	yaw	deg
	rollspeed	deg/s
	pitchspeed	deg/s
	yawspeed	deg/s
GLOBAL_POSITION_INT	lat	deg
	lon	deg
	alt	m
	vx	m/s
	vy	m/s
	vz	m/s
VFR_HUD	airspeed	m/s
	groundspeed	m/s

provides a detailed overview of the measurements provided by these packages.

Figure 11 shows the flowchart describing the communication process between the Pixhawk and the Raspberry Pi 5. Once the script is launched, the Pixhawk transmits data to the Raspberry Pi, using MAVLink protocol, where they are continuously managed and updated until the acquisition is terminated.

3.2. Radar–Raspberry Pi Connection

The IWR1642 radar is connected to the Raspberry Pi 5 via a USB 2.0 cable, which establishes a virtual serial interface (UART over USB). This link allows the Raspberry Pi to send configuration commands to the radar and receive processed data packets in real time.

The radar communicates through a proprietary frame-based serial protocol, transmitting packets that include target range, velocity, and angle information. The data update rate can be configured between 1 Hz and 30 Hz, depending on the operational profile selected, such as short-range detection, multi-target tracking, or environmental mapping.

For power, the IWR1642 cannot draw electricity from the Raspberry Pi and requires connection to 220 V AC mains. To enable mobile operation, the power was adapted using a 220 V AC to 5 V DC converter connected to an external battery, thus allowing the radar to operate independently of the mains power. Maintaining common ground (GND) between the radar and Raspberry Pi is essential to ensure communication stability and reduce electrical noise.

With this setup, the radar serves as a key sensor, providing reliable data for obstacle detection, relative velocity estimation, and sensor fusion with Pixhawk telemetry and other onboard instruments, enhancing the system’s ability to perceive and interpret its environment.

Figure 12 illustrates the schematic of the experimental setup. The radar module is powered by an external source and connected to the Raspberry Pi 5 via USB using the UART protocol, enabling reliable data communication between the devices.

The radar signal is digitized and organized into a Type–Length–Value (TLV) structure, based on the demo being run. This information is then packed into an output structure and sent back to the computer via UART. Each TLV item in the packet payload contains a data type and value (payload) and their length can depend on the number of detected objects and can vary from frame to frame.

The number of TLVs in the frame packet is extracted from the frame header. Each TLV within the packet includes a TLV header containing the type and length information. The type identifier specifies the kind of data contained in the payload, while the length field indicates the payload size [44].

Table 6. Radar TLV data.

TLV Id	Value Type	Description	Data [Unit]
1	Detected Points	Each point is represented by 16 bytes giving position and radial Doppler velocity	x [m] y [m] z [m] v [m/s]
7	Side Info for Detected Points	The payload consists of 4 bytes for EACH point in the point cloud.	SNR [dB] Noise [dB]

reports the two TLV packets that are relevant to this work and extracted from the radar sensor.

Characterization tests were conducted on the IWR1642 radar both in real environments and under controlled conditions at CIRA (Italian Aerospace Research Centre), using a corner reflector placed at a known reference distance, as described in detail in [40]. The previously described data were acquired using software developed in a Python 3.9 environment, which employs the official demo parser provided by Texas Instruments to extract this information.

The analysis showed an accurate correspondence between the distances measured by the radar and the real distances, confirming the reliability of the sensor in distance detection. Based on the results obtained during characterization and on the adopted configuration parameters (

Table 7. Configuration parameters.

Azimuth Resolution	15 deg
Range Resolution	0.044 m
Maximum Unambiguous Range	9.02 m
Maximum Radial Velocity	1 m/s
Radial Velocity Resolution	0.13 m/s
Range Detection Threshold	15 dB
Doppler Detection Threshold	15 dB

), it was decided to prioritize range and velocity resolution over maximum detection range, using the Radar-On-Chip as a proximity sensor. This choice can be justified through the radar range equation, according to which improving the resolution generally requires a reduction in the maximum detectable range.

Data analysis showed that the best performance in terms of resolution (range of 0.044 m and velocity of 0.13 m/s) is achieved within a maximum distance of 9.02 m. Therefore, the sensor will be used primarily for detecting nearby objects, exploiting this optimal distance window to ensure reliable measurements.

Figure 13 shows the flowchart describing the communication process between the IWR1642 Radar and the Raspberry Pi 5. Once the script is launched, Texas Instruments’ official demo parser is imported to manage and update the radar data in an efficient way.

3.3. LiDAR–Raspberry Pi Connection

The HELIOS 16P 3D LiDAR from RoboSense is a multi-beam sensor designed to capture high-resolution three-dimensional data, featuring 16 laser channels and a typical range of up to 150 m. The device is connected to the Raspberry Pi 5 via an Ethernet interface, which allows real-time data transfer using the UDP protocol. This connection ensures high bandwidth and low latency, which is essential for processing dense 3D point clouds.

For power, the sensor requires connection to 220 V AC mains, through a dedicated power adapter that converts the voltage to the LiDAR’s required levels (typically 12 V DC). As with other sensors, maintaining a common ground between the LiDAR and Raspberry Pi is important to ensure stable communication and minimize electrical noise.

With this setup, the HELIOS 16P LiDAR provides the system with a detailed representation of the surrounding environment, significantly enhancing spatial perception, path planning, and the fusion of data with Pixhawk telemetry, the radar, and other vehicle sensors.

Figure 14 illustrates the schematic of the experimental setup. The LiDAR module is powered by an external source and connected to the Raspberry Pi 5 via an Ethernet port, using the UDP protocol, enabling reliable data communication between the devices.

The communication protocols between the LiDAR and the computer fall into two categories: MSOP (main data stream output protocol) and DIFOP (device information output protocol). MSOP packets have a payload of 1248 bytes and encapsulate point cloud data including distance, azimuth angle, and reflection intensity. They are composed of a header (42 bytes), a data block (1200 bytes), and a tail (6 bytes).

As shown in

Table 8. Data block packet definition [45].

Description	Data Block (1200 Bytes)
Data Block Number	Data Block 1	Data Block 12
Flag	0xff, 0xee	0xff, 0xee
Horizontal Rotation Angle	Azimuth 1	Azimuth 12
Channel 1	Channel Data 1	Channel Data 1
…	…	…
Channel 16	Channel Data 16	Channel Data 16

, the data block is composed of 12 individual blocks, each with a length of 100 bytes, representing a complete set of ranging data. Within each 100 byte data block, the space is structured as follows [45]:

• Two bytes for the flag: Represented by the value 0xffee, which indicates the beginning of a new block;
• Two bytes for the azimuth: Indicates the horizontal rotation angle information. Each azimuth angle corresponds to 16 channels of data, containing one complete set of information for 16 channels;
• Three bytes for the Channel data: The high two bytes represent the distance information with a resolution of 0.25 cm, and the low byte represents the reflectivity information.

As the LiDAR data packet contains only horizontal rotation angles and distance parameters, to present a three-dimensional point cloud, the polar coordinates (angle and distance) are transformed into Cartesian coordinates (x, y, z), according to Equation (1):

$$\left\{\begin{array}{c}x=r\cos \left(\omega \right)\cos \left(\alpha \right)+R\cos \left(\alpha \right)\\ y=r\cos \left(\omega \right)\sin \left(\alpha \right)+R\sin \left(\alpha \right)\\ z=r\sin \left(\omega \right)\end{array}\right.$$

(1)

where r is the measured distance, ω is the laser’s vertical angle, α is the laser’s horizontal rotation angle, R is the plane radius from the optical center to the origin, and x, y, z are the coordinates projected onto the Cartesian X, Y, Z axes. In this work, the LiDAR sensor was used in a time-of-flight (ToF) configuration; therefore, only x, y, z LiDAR data were considered, while additional information such as intensity data was not taken into account due to radiative effects. LiDAR characterization tests were performed in both real and controlled environments, as described in detail in [46]. In [46], LiDAR characterization was performed in terms of effective operational range, precision, and accuracy, considering both indoor and outdoor environments to evaluate these parameters under different environmental conditions. The following figures illustrate the LiDAR data collected at known distances during indoor tests (Figure 15 and Figure 16) and outdoor tests (Figure 17 and Figure 18). The acquired measurements are compared with a theoretical Gaussian distribution centered around the corresponding evaluated mean value.

Figure 19 shows the flowchart describing the communication process between the HELIOS 16P LiDAR and the Raspberry Pi 5.

LiDAR Data Correction

Analysis of the raw data recorded on the Raspberry Pi revealed the need to apply a correction of detected points, corresponding to 8 of the 16 LiDAR planes. These corrections are handled automatically by the official software, but the developed system, based on Python 3.9 software, made it necessary to implement these operations manually to ensure fully readable and usable data.

In detail, it was observed that the eight planes associated with odd-numbered channels are rotated clockwise by 10.2°, with respect to the z-axis of the LiDAR reference system. This value was obtained through a series of indoor experimental tests, in which the sensor was placed with its x-axis orthogonal to a flat wall. The acquired data showed distortion only in the odd-numbered channels, while the even-numbered channels returned measurements that were consistent with the expected configuration. To quantify the rotation, points belonging to the wall surface were selected and, using a linear regression line, the angle formed by this line with the y-axis of the LiDAR reference system was calculated.

The angular coefficient m and the constant term q of a generic straight line y = mx + q are found by minimizing the function:

$$\mathcal{F}\left(m,q\right)={\sum _{i=0}^n\left(m\ast x_i+ q-y_i\right) }^2$$

(2)

and are given by:

$$m={\displaystyle \frac{\left(n+1\right){\sum }_{i=0}^n{x}_i{y}_i-{\sum }_{i=0}^n{x}_i{\sum }_{i=0}^n{y}_i}{\left(n+1\right){\sum }_{i=0}^n{x}_i^2-{({\sum }_{i=0}^n{x}_i)}^2}}$$

(3)

$$q={\displaystyle \frac{{\sum }_{i=0}^n{y}_i{\sum }_{i=0}^n{x}_i^2-{\sum }_{i=0}^n{x}_i{\sum }_{i=0}^n{x_{i}y}_i}{\left(n+1\right){\sum }_{i=0}^n{x}_i^2-{({\sum }_{i=0}^n{x}_i)}^2}}$$

(4)

where ${(x}_{i,}{y}_i)$ are the coordinates of a point in the “image” and n + 1 is the number of measurements. Figure 20 shows the obtained regression lines.

The average angle obtained on the odd-numbered channels returned a value of 10.2°, which was then used to construct a rotation matrix that allows the data to be corrected by rotating the acquired points counter-clockwise around the LiDAR z-axis (Equation (5)).

$$R_z=\left[\begin{array}{cc}\begin{array}{c}\cos \Theta \\ \sin \Theta \end{array}& \begin{array}{c}\begin{array}{cc}-\sin \Theta & 0\end{array}\\ \begin{array}{cc}\cos \Theta & 0\end{array}\end{array}\\ 0& \begin{array}{cc}0& 1 \end{array}\end{array}\right]$$

(5)

Misaligned error compensation is shown in Figure 21.

3.4. Data Fusion Method

An additional Python 3.9 software has been developed to manage the synchronization and fusion process of the data acquired by Pixhawk, radar, and LiDAR sensors. The system architecture was designed to ensure efficient and robust acquisition, based on a FIFO (first in, first out) queue logic that allows only the latest sample available for each sensor to be stored in memory, thus reducing the computational load on the Raspberry Pi and preserving the responsiveness of the process.

The fusion of data from radar and LiDAR sensors is achieved through an extended Kalman filter (EKF) algorithm, integrated within dedicated modules and used to obtain a consistent and refined estimate of the position of the obstacles in the surrounding environment [47,48]. This approach compensates for the individual limitations of the sensors, improving the reliability of the measurements and the overall robustness of the perception system, and mitigating noise, correcting bias, and enhancing the overall distance estimation precision.

The measurement process model is [49]:

$$x_{k+1} = f(x_k, u_k,{\upsilon }_k)$$

(6)

$$z_k=g(x_k, u_k, v_k)$$

(7)

where x is the state, u is the input, z is the measured output, υ and v are the process and measurement noise, respectively. Zero-mean Gaussian distributions are assumed for the noises υ_k and v_k, with known covariance matrices Q_k and R_k:

$${\upsilon }_k\sim \mathcal{N}\left(0, Q_k\right) v_k\sim \mathcal{N}(0, R_k)$$

(8)

The algorithm is divided into two phases: prediction and correction. At each time step, the prediction phase provides the a priori state estimation ${\widehat{x}}_{k+1}^{-}$ and the state covariance matrix $P_{k+1}^{-}$, whereas, during the correction phase (update phase), the a posteriori state estimation ${\widehat{x}}_{k+1}^{+}$ and the state covariance matrix $P_{k+1}^{+}$ are calculated.

The a priori estimation of the state ${\widehat{x}}_{k+1}^{-}$ is expressed by Equation (6), considering null process noise ${(\upsilon }_k=0)$:

$${\widehat{x}}_{k+1}^{-} = f\left({\widehat{x}}_k^{+}, u_k,0\right)$$

(9)

The a priori state covariance matrix $P_{k+1}^{-}$ is obtained as follows:

$$P_{k+1}^{-}=A_k P_k^{+} A_k^T+W_k Q_k W_k^T$$

(10)

where

$$A_k={\left({\displaystyle \frac{\partial f}{\partial x}}\right)}_{\begin{array}{c}{\widehat{x}}_k^{+}, u_k,0\\ 1\end{array}} W_k={\left({\displaystyle \frac{\partial f}{\partial \upsilon }}\right)}_{\begin{array}{c}{\widehat{x}}_k^{+}, u_k,0\\ 1\end{array}}$$

(11)

are the Jacobian matrices of the function f, and $P_k^{+}$ is the a posteriori state covariance matrix at time k. Once a new measurement has been acquired, the a posteriori state estimation can be computed by updating the a priori state estimation, as:

$${\widehat{x}}_k^{+}= {\widehat{x}}_k^{-}+K_k(z_k-h({\widehat{x}}_k^{-}\left)\right)$$

(12)

where the Kalman gain (K_k) is given by:

$$K_k=P_k^{-} H_k^T{\left(H_k{P}_k^{-}{H}_k^T+{V_{k}R}_k{V}_k^T\right)}^{-1}$$

(13)

Finally, the a posteriori state matrix is updated as follows:

$$P_k^{+}=\left(I-K_k{H}_k\right)P_k^{-}$$

(14)

To apply the EKF, a calibration procedure was carried out to ensure optimal filter performance. The measurement noise covariance matrices (R) were determined based on the results of the sensor characterization phase that was previously performed for both the LiDAR and the radar. The process noise covariance matrix (Q) was set to a very small value, assuming a slowly varying system model.

The initial state covariance matrix (P) was initialized as the identity matrix (I), following standard Kalman filter practice. This configuration allowed the EKF to properly converge while balancing the relative confidence between the model and the sensor measurements.

Table 9. Parameters values for EKF calibration.

Parameter	Value
Initial State x	[0, 0, 0, 0, 0, 0]
${\mathsf{\sigma }}_{\mathrm{R}}^2$(m2)	0.8
${\mathsf{\sigma }}_{\mathrm{L}}^2$(m2)	0.006
${\mathsf{\sigma }}_{\mathrm{Q}}^2$(m2)	0.1
P	I(6)
RR	${\mathsf{\sigma }}_{\mathrm{R}}^2$· I(2)
RL	${\mathsf{\sigma }}_{\mathrm{L}}^2$· I(2)
Q	${\mathsf{\sigma }}_{\mathrm{Q}}^2$· I(6)

shows the parameters used during the EKF initialization phase: ${\sigma }_R^2$and ${\sigma }_L^2$ indicate noise covariance for radar and LiDAR, respectively, used for R_R and R_L, which are covariance matrices measurements for radar and LiDAR, respectively; ${\sigma }_Q^2$ is covariance noise used to process covariance matrix Q.

Figure 22 shows EKF implementation during the primary tests performed.

3.5. Data Visualization

Subsequently, the latest telemetry and obstacle detection data are packaged and transmitted via two separate UDP ports. These communication channels have been designed to be read by additional software dedicated to runtime visualization, allowing for a clear separation between data acquisition and processing logic and graphic representation logic. This strategy ensures non-blocking operation and minimizes the latency associated with accessing the latest sensor sample. Figure 23 shows the flowchart of the sensors fusion.

Figure 24 shows the GUI (graphical user interface) created for runtime data visualization. The interface aggregates information into four main sections:

• Attitude, which reports the vehicle’s attitude using Euler angles and angular velocities;
• Position, which shows the geographical position (latitude, longitude, altitude) and linear velocities expressed in the NED reference system;
• Velocity, which represents the speeds, relative to the air and the ground;
• Obstacle detection, which displays the position of the nearest obstacle, expressed in terms of distance and azimuth.

The “obstacle detection” box also features a warning indicator that activates when an obstacle is detected at a distance that is less than a safety threshold. This threshold is defined dynamically, based on the speed of the vehicle, in order to consider variable reaction times as speed changes, and is further modulated according to the direction of travel, to selectively detect only obstacles that are actually relevant to the trajectory of motion.

3.6. Testing of Developed System

For testing and validating the operational capability of the developed system, a series of simulation tests were conducted. Specifically, these tests aimed to monitor the stability of the communication channels developed and data integration between the Raspberry Pi and the two sensors (radar, LiDAR) with autopilot, and to validate the consistency of the acquired data.

Subsequent tests were conducted at the outdoor facilities of CIRA (Italian Aerospace Research Center). For these experiments, the simulated UAV platform, together with the radar and LiDAR sensors, was integrated and mounted on a rotary structure (Figure 25) that was capable of simulating realistic UAS flight conditions.

For both sensors, the x–y coordinates were considered within the same horizontal plane, as the two sensors were rigidly mounted and geometrically aligned on the platform. A small offset along the z-axis, approximately 7 cm, was present due to the physical mounting configuration.

This alignment configuration implies that:

−

The origins of the LiDAR and radar reference frames coincide in the horizontal plane;

−

The sensor axes are parallel.

$${\mathit{R}}_{R-L}=\mathit{I}, {\mathit{t}}_{R-L}=0$$

where ${\mathit{R}}_{R-L}$ and ${\mathit{t}}_{R-L}$ denote the rotation and translation between radar and LiDAR frames, respectively. Under this assumption, both sensors share a common sensor reference frame, with a small offset along the z-axis.

During the tests, the system was evaluated in the presence of both static obstacles (e.g., buildings and trees) and dynamic obstacles (e.g., vehicles and pedestrians) positioned along the simulated flight trajectory.

The tests were performed in different scenarios, simulating several navigation trajectories within complex environments.

To define the UAV position and orientation, two reference frames are considered [50]:

–

Common sensors frame (LiDAR and radar) ($F_S$): A coordinate system that is rigidly attached to the LiDAR–radar sensor assembly, in which both LiDAR and radar measurements are expressed.

$$F_S=(X_S, Y_S, Z_S)$$

–

Body reference frame ($F_B$): Centered in the center of gravity (CG) of the simulated UAV, with:

$$F_B=(X_B, Y_B, Z_B)$$

With X_B–axis positive forward, Y_B–axis positive rightward, and Z_B–axis to form a right-handed reference frame.

–

Local navigation frame ($F_N$): north–east–down (NED) frame, centered at the GNSS antenna phase center:

$$F_N=(N, E, D)$$

–

Global Earth-fixed frame:

• ECEF (Earth-centered Earth-fixed);
• WGS84 geodetic coordinates (latitude, longitude, ellipsoidal height).

A generic measurement acquired by either sensor (LiDAR or radar) is represented in the common sensor frame as [51]:

$${\mathit{p}}_S=\left[\begin{array}{c}{x}_S\\ \begin{array}{c}{y}_S\\ z_S\end{array}\end{array}\right]$$

(15)

where the coordinates are derived from the measured range and scanning angles, after data fusion method application for both sensors. Because of perfect alignment, no inter-sensor transformation is required.

The spatial relationship between the sensor assembly and the simulated UAV body frame is defined by:

–

Lever arm vector:

$${\mathit{t}}_{BS}=\left[\begin{array}{c}\Delta x\\ \begin{array}{c}\Delta y\\ \Delta z\end{array}\end{array}\right]$$

(16)

–

Boresight rotation matrix:

$${\mathit{R}}_{BS}$$

representing the fixed rotational offset between the sensor frame and the UAV body frame.

The transformation is expressed as:

$${\mathit{p}}_B={\mathit{R}}_{BS}\ast {\mathit{p}}_S+{\mathit{t}}_{BS}$$

(17)

This transformation is identical for both LiDAR and radar measurements.

The UAV platform orientation during the experiments was provided by the onboard inertial measurement unit (IMU), integrated into the Pixhawk 2.4.8 flight controller. The attitude was expressed in terms of roll ($\Phi$), pitch ($\theta$), and yaw ($\Psi$) angles.

The rotation matrix from body frame to navigation frame (NED) is defined as:

$${\mathit{R}}_{NB}=R_z\left(\Psi \right){ R}_y\left(\theta \right) R_x\left(\Phi \right)$$

(18)

The point coordinates in the navigation frame are computed as:

$${\mathit{p}}_N={\mathit{R}}_{NB}\ast {\mathit{p}}_B+{\mathit{t}}_{GNSS}$$

(19)

where ${\mathit{t}}_{GNSS}$ denotes the UAV position obtained from GNSS receiver measurements.

Figure 26 illustrates the trajectory followed during test 1. The green and yellow segments indicate the presence of nearby obstacles along the path, corresponding to the “free” and “alert” risk levels, respectively. The red line represents the reconstructed scenario obtained through LiDAR–radar data fusion, with spike errors removed to improve spatial consistency.

The following considerations were applied during these tests:

−

The simulated UAV motion was constrained to the horizontal plane only;

−

A 120° LiDAR field of view (from −60° to +60°, with respect to the sensor forward axis) was used instead of the full 360°, to reduce computational load;

−

Variations along the z-axis were not considered.

Figure 27 and Figure 28 illustrate the UAV trajectories in two different test scenarios.

4. Conclusions

The obtained results confirm the validity of the proposed approach for integrating heterogeneous sensor data within a single application dedicated to obstacle detection along a UAS navigation trajectory. The development of a fully functional hardware–software platform that is capable of acquiring, synchronizing, and merging LiDAR and radar data together with the flight controller information in real time demonstrates that the primary objective of this work has been successfully accomplished.

The combined use of LiDAR and radar sensors, together with the UAV state information provided by the autopilot, significantly enhances the perception reliability compared to the use of individual sensors alone. Indeed, LiDAR provides high accuracy and precise distance measurements, compensating for radar’s lower spatial resolution. Conversely, mmWave radar operates reliably through fog, rain, and darkness where LiDAR fails, while also providing instantaneous velocity data via the Doppler effect. By fusing these sensors, the system ensures robust detection and all-weather performance that neither sensor could achieve alone.

This result is consistent with findings reported in the literature, where sensor fusion is recognized as a key strategy for improving measurement robustness under uncertain and dynamic operating conditions.

Moreover, the adopted hardware–software architecture, based on FIFO queues and dedicated processing threads for each data stream, enables low-latency and continuous data handling, which are essential requirements for DAA systems.

During simulation tests, transmission delays of approximately one minute were initially observed in the MAVLink navigation data stream. The introduction of FIFO queue-based data management reduced these delays to approximately one second.

To further minimize latency, future developments will involve re-implementing the processing modules in the C programming language instead of Python 3.9. This choice is expected to significantly reduce computation time, as C is a compiled language, whereas Python 3.9 relies on interpreted execution.

From an application standpoint, the results indicate that the proposed platform can serve as a solid foundation for the development of more advanced DAA algorithms, where the real-time estimation of obstacle distance and azimuth enables autonomous generation of corrective trajectories. Moreover, the modular design of the architecture allows for seamless integration of additional sensors, communication protocols, or enhanced data fusion strategies.

Future work will focus on implementing obstacle avoidance capabilities, enabling the system to not only detect obstacles but also to autonomously perform real-time evasive maneuvers.