# FESTA: FPGA-Enabled Ground Segmentation Technique for Automotive LiDAR

## Abstract

The automotive industry keeps moving fast toward the development of smarter, safer, and more sustainable autonomous vehicles. Today, these come equipped with advanced driver assistance systems (ADAS), which include sophisticated perception technologies to safely navigate the environment. One of the key sensors present in the perception system is light detection and ranging (LiDAR). It can accurately measure distances to objects and create detailed real-time 3-D maps of the surrounding environment, including obstacles and road boundaries. Extracting the road information to identify the drivable area is one of the most important steps applied to a LiDAR output; however, due to the amount of data a high-resolution sensor generates, this task becomes quite challenging. This article proposes FESTA, a ground segmentation technique accelerated in field-programmable gate arrays (FPGAs) using the ALFA framework, that can execute the ground segmentation step applied to the sensor output in real time. The performed evaluation shows that FESTA requires, on average, 8.92 ms for processing a point cloud frame from a VLP-16 sensor, 14.41 ms for an HDL-32, 40.87 ms for an HDL-64, and 70.59 ms for a VLS-128, while outperforming state-of-the-art algorithms in other performance metrics.

## Authors

José Carvalho *Centro ALGORITMI/LASI, Universidade do Minho-Campus Azurém, Guimarães, Portugal*

Luís Cunha *Centro ALGORITMI/LASI, Universidade do Minho-Campus Azurém, Guimarães, Portugal* [ORCID: 0009-0008-6762-8018](https://orcid.org/0009-0008-6762-8018)

Sandro Pinto *Centro ALGORITMI/LASI, Universidade do Minho-Campus Azurém, Guimarães, Portugal* [ORCID: 0000-0003-4580-7484](https://orcid.org/0000-0003-4580-7484)

Tiago Gomes *Centro ALGORITMI/LASI, Universidade do Minho-Campus Azurém, Guimarães, Portugal* [ORCID: 0000-0002-4071-9015](https://orcid.org/0000-0002-4071-9015)

## Publication Information

**Journal:** IEEE Sensors Journal **Year:** 2024 **Volume:** 24 **Issue:** 22 **Pages:** 38005-38014 **DOI:** [10.1109/JSEN.2024.3470591](https://doi.org/10.1109/JSEN.2024.3470591) **Article Number:** 10705951 **ISSN:** Print ISSN: 1530-437X, Electronic ISSN: 1558-1748, CD: 2379-9153

## Metrics

**Paper Citations:** 5 **Total Downloads:** 327

## Funding

- Fundação para a Ciência e Tecnologia (FCT) within the Research and Development Units Project Scope (Grant: UIDB/00319/2020 and 2023.01007.BD)

---

## Keywords

**IEEE Keywords:** Sensors, Point cloud compression, Roads, Laser radar, Real-time systems, Automotive engineering, Prediction algorithms, Accuracy, Hardware, Fitting

**Index Terms:** Light Detection And Ranging, Ground Segment, Performance Metrics, Point Cloud, Autonomous Vehicles, Automotive Industry, Perceptual System, Advanced Driver Assistance Systems, High-resolution Sensors, Real-time Output, Road Boundary, Cell Size, Processing Time, Performance Of Algorithm, Intersection Over Union, Case Scenario, Grid Size, Lookup Table, Ground Plane, Total Processing Time, Ground Points, Resource Costs, Hardware Accelerators, Point Cloud Processing, Minimum Elevation, Hardware Implementation, Random Sample Consensus, Hardware Resources, Point Cloud Data

**Author Keywords:** Autonomous vehicles, embedded systems, field-programmable gate array (FPGA), ground segmentation, light detection and ranging (LiDAR), perception systems

undefined
## SECTION I. Introduction

Over the years, the automotive industry has been facing several important technological revolutions, which highly impact societies and mobility worldwide [^1]. While the shift from fuel-based to electrical engines is one of the most significant transformations of this decade, the goal of achieving full driving automation features keeps gathering attention from research and industry players. According to SAE International, vehicle automation can be categorized into six levels [^2], where levels 0–2 require driver interaction and monitoring of the vehicle, and levels 3–5 introduce features that enable the vehicle to operate autonomously across the driving scenario. Most modern vehicles today can already provide level-2 features, which include improved advanced driver assistance systems (ADAS) relying on data from different sensor technologies to enable the efficient reading of the vehicle’s surroundings and assist the driving tasks [^3], [^4].

Among all sensors present in the perception system, light detection and ranging (LiDAR) stand out for their ability to measure accurate distances to objects and create detailed 3-D point clouds of the surrounding environment in almost every light condition [^5]. Such features can help the autonomous vehicle in performing several tasks, such as obstacle detection, identification, avoidance [^6], [^7], [^8], [^9], [^10], and road and ground recognition for vehicle’s navigation [^11], [^12]. However, to efficiently perform these tasks, a LiDAR must provide high-resolution point clouds in real time, which consequently increases the amount of data being transmitted and further handled by the processing system [^13].

One well-known technique to reduce the point cloud size to be processed is data segmentation [^14], which consists of identifying and separating specific points from the remaining data. The output from this step is a new point cloud that can be used for different tasks. While object identification and classification can perform better after the ground points are removed, the road navigation task can perform better if only ground data is processed. Nonetheless, performing the ground segmentation step can come at the cost of computational resources, since high-resolution point clouds often require robust processing systems and available memory for achieving real-time execution [^15]. Moreover, in an automotive scenario, most processing platforms are embedded systems with resource constraints, which hampers the utilization of these algorithms close to the sensor.

This article presents FESTA, a ground segmentation technique assisted by field-programmable gate array (FPGA) technology for LiDAR sensors used in automotive applications. The main contributions of this article are: 1) a hardware-based ground segmentation algorithm for automotive LiDAR sensors; 2) a detailed overview of the algorithm’s main steps, its implementation over the ALFA framework, and all its main components and key features; and 3) a comprehensive evaluation and benchmarking of the proposed solution.

## SECTION II. LiDAR Ground Segmentation

Ground segmentation for autonomous vehicles is a research topic that has been thoroughly studied over the last few years. Current ground segmentation methods found in the literature can be divided into five main categories [^14], ranging from complex algorithms that require high computational resources, to more straightforward implementations that can achieve real-time requirements. The tradeoff between real-time features, computational requirements, and the overall algorithm’s performance dictates whether a method from one category should be adopted over the others. Regarding autonomous applications with real-time requirements, plane-fitting-based approaches can offer a good balance between complexity and overall algorithm performance [^14]. The principle behind this approach consists of translating the ground geometry using a single plane or a grid of planar surfaces, where given a set of points, the plane that minimizes the orthogonal distances between the points and the plane is identified. Then, the distance of each point is compared with different threshold values to identify and label ground data.

Table I summarizes the state-of-the-art plane-fitting algorithms, comparing them in terms of complexity, the time required to process a point cloud frame for the chosen dataset, and performance metrics such as Precision, Recall, and the $F1$-score. Although Accuracy and the Intersection over Union (IoU) are also used for evaluating performance, these metrics are not provided in the current literature. All of these metrics depend on the prediction values given by the true positive (TP), true negative (TN), false positive (FP), and false negative (FN) ratios. They help evaluate the algorithm’s ability to correctly detect and label/remove ground points from the point cloud. Precision (1) represents the number of ground points correctly detected of all the ground points, and the Recall (2) measures the number of ground points correctly detected within the point cloud. The $F1$-score (3) provides the combined information of Precision and Recall by a harmonic mean of both, and the accuracy indicates the ratio of correctly predicted points to the total number of points (4). Finally, the IoU indicates the ratio of the overlapping area between the predicted and ground-truth regions to the area of their union (5)

$$
\begin{align*} {\mathrm { Precision}} & = \frac {\mathrm { TP}}{\mathrm { TP + FP}} \tag {1}\\ {\mathrm { Recall}} & = \frac {\mathrm { TP}}{\mathrm { TP + FN}} \tag {2}\\ {F}_{1} & = {2} \times \frac {{\mathrm { Precision}} \times {\mathrm { Recall}}}{\mathrm { Precision + Recall}} \tag {3}\\ {\mathrm { Accuracy}} & = \frac {\mathrm { TP + TN}}{\mathrm { TP + FP + TN + FN}} \tag {4}\\ {\mathrm { IoU}} & = \frac {\mathrm { TP}}{\mathrm { TP + FP + FN}}. \tag {5}\end{align*}
$$

![Figure 1](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t1-3470591-large.gif)

*TABLE I*

All the implementations summarized in Table I were tested in urban automotive scenarios. Although the tests were conducted under different conditions—varying datasets and setups—it is still possible to assess their accuracy independent of the hardware used. In cases where the authors collected their datasets for evaluation [^16], [^17], [^18], the results remain comparable as they reflect real-world scenarios. However, the processing time is highly dependent on several factors: the complexity of the algorithm, the LiDAR sensor used, and the computational system selected to run the algorithms.

Hu et al. [^19] proposed a plane-fitting approach based on the random sample consensus (RANSAC) algorithm. It uses a short-term memory technique to address the accuracy issues in predicting the ground plane, but this approach increases the algorithm’s complexity, resulting in approximately 600 ms to process a single point cloud frame from the KITTI Vision Benchmark Suite dataset. In addition to not providing real-time performance, it mainly works well on flat surfaces, achieving the lowest $F1$-score, likely due to the assumption of a single ground plane. Zhang et al. [^16] also proposed a method based on the RANSAC algorithm. This method achieved a frame processing time of 12 ms in a real-world scenario, with the vehicle traveling 2.9 km at an average speed of 28.6 km/h. However, the $F1$-score was among the lowest. In addition, the curb detection algorithm failed in the presence of obstructions, which reduced the overall performance of the algorithm.

Sun et al. [^17] proposed a method tested in a real-world scenario that achieved real-time performance with a frame processing time of 36.5 ms with good accuracy results. The evaluation included four different road typologies: straight urban roads, curved roads, roads with varying widths with curbstones, and roads with low borders. Although this method is similar to the work proposed by Zhang et al. [^16], the achieved results are slightly better. This is mainly due to the implementation of a feature that can estimate the road boundaries even when the view is obstructed. This enhances adaptability across diverse road conditions and serves as a preventive measure against obstacles. However, this approach often fails at estimating the road boundaries in intersections, a common issue with curb detection algorithms. Lim et al. [^20] proposed Patchwork, a plane-fitting approach that is based on the principal component analysis (PCA) instead of the RANSAC algorithm, resulting in a simpler but faster solution. In addition to the PCA, it includes a Ground Likelihood Estimation (GLE) step to increase precision and the algorithm’s immunity to under-segmentation. However, a discontinuity of the ground plane sometimes happens due to the lack of interaction between neighboring bins, which are the polar grid map subdivision elements. This leads to increased difficulty when extracting objects close to the ground.

Lee et al. [^21] improved Patchwork and developed Patchwork++, a method that leverages adaptive GLE (A-GLE) to dynamically calculate suitable parameters based on the previous ground segmentation results. In addition, Patchwork++ tackles partial under-segmentation challenges by employing temporal ground revert (TGR), which utilizes temporary ground properties. Also, region-wise vertical plane fitting (R-VPF) is introduced to segment the ground plane properly even if the ground is elevated with different layers. Patchwork++ was also tested with the SemanticKITTI dataset, requiring around 18.23 ms to process a point cloud frame, achieving a Precision of 94.92%, a Recall score of 98.18%, and an $F1$-score of 96.51%. Josyula et al. [^22] proposed a method also based on the RANSAC algorithm. Tested with the KITTI Vision Benchmark Suite dataset, it can achieve real-time performance, although no other performance metrics are disclosed. Tested by Anand et al. [^18] with their own dataset, the approach obtains the best precision results among all other methods. However, the Recall is relatively low.

Finally, the work proposed by Anand et al. [^18] provides a comprehensive evaluation using various datasets and computational setups. When tested with their own dataset, the Recall is 99.49% and the $F1$-score is 99.54%. However, this dataset does not comprehensively represent a driving scenario. Nonetheless, with the Paris-Lille 3-D dataset, the algorithm achieved a Precision of 98.69%, a Recall of 97.96%, and an $F1$-score of 98.32%, proving the algorithm’s effectiveness. The best processing time (second from the list) was achieved with the KITTI dataset, corresponding to the 12.69 ms required to process a point cloud frame. However, the computational system used is by far the most powerful. When tested with the platform with lower hardware resources (NVIDIA Jetson TX2) and a dataset recorded with a Velodyne VLP-32, the frame processing time is around 37.03 ms. Despite presenting the best performance results with a real-world dataset, achieving the real-time requirements with high-resolution sensors can become a hard task, even with more robust setups.

Targeting embedded platforms with acceleration capabilities, the proposed FESTA algorithm follows the work proposed by Anand et al. [^18]. Its main goal is to reduce the overall frame processing time, while maintaining the other performance metrics, to support high-resolution sensors. The main differences from the original work are: 1) a fixed-size cell grid to reduce one step from the algorithm and to save hardware resources on embedded platforms; 2) new thresholds for the ground classification step; and 3) the support for hardware accelerators to achieve real-time performance, even with high-resolution sensors.

## SECTION III. FESTA: Design and Implementation

### A. Design

FESTA proposes a fixed-size cell grid to reduce the execution time. This fixed geometry improves the execution time and allows the algorithm to be deployed on embedded platforms with limited hardware without allocating unnecessary resources. Contrary to the original version, our algorithm requires only two steps for performing the ground segmentation, the grid creation, and the ground points classification.

#### 1) Grid Creation:

Building the cell grid requires only one iteration through the point cloud frame, as described in Algorithm 1. To populate the grid, it is first necessary to define its width and length in terms of the number of cells, which is directly related to the sensor’s range and resolution and must be tuned before its deployment. In turn, the size of the cell is directly related to the grid resolution and must also be considered. For instance, designing a cell grid of $128 \times 128$ cells [length $\times$ width], with a cell size of 0.5 m, results in a grid covering an area of $64 \times 64$ m. Increasing the cell size to 1 m would increase the range to $128 \times 128$ m, but would reduce the resolution of the final grid, which may affect the performance results. The fixed-size cell grid allows for improved resource planning and allocation in scenarios where computational resources are limited or need to be efficiently managed, such as hardware accelerators.

![Figure 2](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes4-3470591-large.gif)

*Algorithm 1 FESTA: Grid Creation Algorithm*

Each cell can be directly accessed using a single address, $\text {cell}_{\text {index}}$, instead of using both $\text {cell}_{x}$ and $\text {cell}_{y}$, resulting in more efficient memory access. These addresses are generated by normalizing the *X*- and *Y*-coordinates to create a grid with the origin in (0, 0)—using the expressions in lines 6 and 7 from Algorithm 1. This removes the problems caused by negative coordinates and allows for contiguous memory address allocation. Calculating $\text {cell}_{x}$ and $\text {cell}_{y}$ is done by taking the normalized *X* and *Y* values and the chosen cell size for the grid—using the expressions from lines 8 and 9 in Algorithm 1. Accessing the cell is done using the expression in line 11, which takes the normalized values of *X* and *Y* and the grid’s width to create a single address based on $\text {cell}_{x}$ and $\text {cell}_{y}$. The cells in the grid were indexed in row-major order, although the algorithm’s behavior remains unchanged regardless of the order chosen. However, this step is only done if the point is within the grid’s perimeter.

Points that fall out of the grid boundaries, that is, points at higher distances from the sensor, are discarded from further processing. In the automotive context and considering the sparsity of the point clouds at greater distances, distant points are likely to be considered noise, and not useful to represent any relevant object or obstacle. Therefore, if the grid is adequately sized and the number of discarded points is minimal, it is possible to achieve a good tradeoff between performance and resource utilization.

#### 2) Ground Segmentation:

The ground classification step (Algorithm 2) starts by retrieving the minimum and maximum *Z* values within each cell, calculated during the grid creation phase. By exploiting their vertical distribution, points from the ground level can be effectively identified. A cell is only eligible for ground removal if it contains points, and if its minimum elevation ($\text {z}_{\min }$) falls below an elevation threshold $\zeta$. This prevents the classification as the ground of cells that only contain higher elevation points. Next, $\text {z}_{\text {sub}}$ is calculated, which corresponds to the difference between each cell’s maximum ($\text {z}_{\max }$) and minimum ($\text {z}_{\min }$) elevations. If this difference is higher than an elevation threshold $\epsilon$, which indicates significant variation in the elevation within the cell, all points within $\text {z}_{\min }$ and a distance threshold of $\text {z}_{\min } + \delta$ are classified as ground. Finally, in scenarios where $\text {z}_{\text {sub}}$ is lower than $\epsilon$, the points may correspond to small objects within that cell. In such cases, all points with *Z* values below $\text {z}_{\min } + \text {z}_{\text {th}}$ are classified as ground, where $\text {z}_{\text {th}}$ takes the value of $\text {z}_{\text {sub}}$ divided by a fraction *f* (Algorithm 2, line 6). This parameter *f* ensures that only part of $\text {z}_{\text {sub}}$ is considered when identifying ground points. By adjusting its value, the sensitivity of the classification process can be tuned, allowing for small objects to be kept in the point cloud.

![Figure 3](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes5-3470591-large.gif)

*Algorithm 2 FESTA: Ground Classification Step*

All of these parameters and thresholds, $\zeta$, $\epsilon$, $\delta$, *f*, and $\text {cell}_{\text {size}}$, can be customized to tune the behavior of the algorithm according to the sensor and the driving environment. Moreover, and contrary to the original method, the classification is done by sequentially processing all the points in the point cloud frame, which significantly improves the throughput and reduces the latency when compared to random accesses to the memory. These improvements, allied to the fixed-sized grid, help in achieving better execution performance ratios.

### B. Architecture

FESTA was deployed over the ALFA framework,[^24] an open-source tool targeted to prototyping, implementing, and validating LiDAR-based algorithms for autonomous applications. Its architecture, depicted in Fig. 1, supports different development environments, such as Desktop and embedded platforms, including those with FPGAs to support the development of custom accelerators to process point cloud data. The software layer runs on top of a Linux distribution system with ROS2 support, which allows for easy integration with other ROS2-based applications or third-party libraries, such as the Point Cloud Library (PCL) [^23]. The framework also includes the ALFA-Monitor tool to visualize point cloud data, configure extension parameters, and monitor user-defined metrics.

![Figure 4](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes1-3470591-large.gif)

*Fig. 1. FESTA system architecture.*

The baseline to develop and run any extension either in the Desktop or embedded environment is the ALFA-Node, an ROS2-based component that is responsible for receiving sensor data, performing point cloud processing algorithms, publishing the processed point cloud to other applications, and configuring the extensions. Its hardware counterpart, the ALFA-Unit, is responsible for accommodating hardware accelerators to support the most time-consuming steps of the algorithm. The software and hardware co-design enables components to communicate seamlessly via AMBA communication buses such as AXI4. Three versions of the FESTA algorithm were developed using the framework: (1) a Desktop-based software extension used to validate performance and compare the algorithm with the original proposal by Anand et al. [^18], Patchwork [^12], and Patchwork++ [^21]; (2) an embedded software-based version to assess the execution performance bottlenecks; and (3) finally, a hardware-accelerated extension deployed in FPGAs to improve the execution performance while keeping the overall performance metrics.

### C. Software Implementation

The integration with ALFA-Node enables the FESTA extension to receive and publish point clouds, change parameters through an ROS2 configuration service (used in the ALFA-Monitor), and transmit the ground segmentation performance metrics and the real-time status of the extension. The FESTA extension was deployed using the parameter values present in Table II, including the grid size (width $\times$ length), cell size, and the thresholds for the classification: $\zeta$, $\epsilon$, $\delta$, and *f*.

![Figure 5](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t2-3470591-large.gif)

*TABLE II*

### D. Hardware Implementation

The hardware implementation comprises several IP blocks already provided by the ALFA framework for handling the extension, and new hardware blocks developed to include the FESTA algorithm. This accelerator includes two fundamental blocks: 1) the *Cell Grid Core*, which is responsible for creating and populating the grid. Upon receiving a new point cloud, it assigns points to their respective cells and calculates the threshold values for the classification step; and 2) the *Ground Segmentation Core* that is used to classify the points as ground or nonground. Although some steps are required to run sequentially, taking the benefits of a hardware-based solution, FESTA leverages a fully pipelined processing to improve efficiency and increase the throughput, ensuring that computational resources are optimally utilized. In addition, the FESTA architecture deploys two BRAM blocks to temporarily store the point cloud and manage necessary information for the points classification. The *Grid BRAM* stores the information of each cell and the corresponding points, which includes the minimum and maximum Z coordinates of the cell, while the *Points BRAM* stores the individual points information necessary for the segmentation, such as the *Z*-coordinate and $\text {cell}_{\text {index}}$, which corresponds to a logical pointer to the corresponding cell address in the *Grid BRAM*.

## SECTION IV. Evaluation

### A. Evaluation Setup

The FESTA algorithm was evaluated using the three ALFA development setups: Desktop, embedded software, and embedded software with hardware acceleration support. The desktop computer consisted of an AMD Ryzen 6800 HS processor with 8 CPU cores running at a clock speed of 3.2 GHz with 16 GB of RAM. The ALFA framework was running on top of an Ubuntu 22.04.3 LTS Linux distribution with the PCL version 1.12.1 and the ROS2 Humble distribution. The embedded setup included a ZCU104 Evaluation Kit, featuring the Zynq UltraScale+ MPSoC. This MPSoC features a quad-core Arm Cortex-A53 application processor, a dual-core Cortex-R5 real-time processor, and FPGA technology with 504 K system logic cells and 1728 Digital Signal Processing (DSP) slices, supported by 2 GB of DDR4 memory.

The evaluation focuses on the performance of the FESTA algorithm for different grid and cell sizes, and with different regions of interest (ROIs) of the point cloud. It uses different public datasets (as summarized in Table III), with data retrieved from four Velodyne LiDAR sensors in different environments:

1. The self-driving Lincoln MKZ dataset [^25], which includes data from a Velodyne VLP-16 and comprises 573 frames collected at a frame rate of 10 Hz, with each frame containing, on average, around 25138 points.
2. The sequence 2018-07-25-11-25-10 from the UMA-SAR dataset [^26], which captures a ground vehicle equipped with a Velodyne HDL-32, moving autonomously in a nonurban outdoor environment. This dataset includes 2944 frames at 10 Hz, with an average point cloud size of 41794 points per frame.
3. The sequences 00 (4541 frames, 121494 points/frame), 01 (1101 frames, 105682 points/frame), 02 (4661 frames, 105682 points/frame), 06 (1101 frames, 122300 points/frame), and 10 (1201 frames, 125910 points/frame) from the SemanticKITTI dataset [^27], which captures a vehicle with a Velodyne HDL-64 at 10 Hz driving through different environments.
4. the Drives sequence 000000 from the Zenseact [^28] dataset, which was recorded with a Velodyne VLS-128 on a highway with heavy traffic, consisting of 2859 frames at a frame rate of 10 Hz, with an average number of 206612 points/frame.

![Figure 6](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t3-3470591-large.gif)

*TABLE III*

The algorithm’s performance evaluation metrics include: 1) Precision (1); 2) Recall (2); 3) $F1$-score (3); 4) Accuracy (4); and 5) the IoU (5). For a better understanding of which grid/cell size values suit better for a given sensor, it also indicated the number of points that were left outside the selected grid. In addition, the execution performance on both the embedded software and the hardware accelerator and the required FPGA resources are analyzed.

### B. Grid Size Versus Cell Size

The grid size is statically selected according to the selected sensor/dataset. The main goal of this step is to avoid allocating unnecessary resources for empty cells while keeping as many points inside the grid as possible. Fig. 2 displays different configurations for a cell size of 0.5 m, while Table IV summarizes some of the chosen setups for different cell sizes (0.25, 0.5, and 1 m) using Seq. 00 of the SemanticKITTI dataset. Using a cell size of 0.25 m would require a bigger grid size (penalizing the required resources to organize and store the point cloud frame, and the algorithm’s execution time), while a cell size of 1 m helps in saving resources and the execution time, but reduces the algorithm’s performance as cells containing more points are more prone to wrong classifications of ground/nonground cells. Therefore, and also used in the work of Anand et al. [^18], the cell size that provides the best results is 0.5 m.

![Figure 7](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t4-3470591-large.gif)

*TABLE IV*

![Figure 8](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes2abcdef-3470591-large.gif)

*Fig. 2. Different grid sizes with a cell size of 0.5 m, for Velodyne HDL-64. (a) Grid with $128\times 128$ cells. (b) Grid with $256\times 256$ cells. (c) Grid with $512\times 512$ cells. (d) Grid with $256\times 128$ cells. (e) Grid with $512\times 128$ cells. (f) Grid with $512\times 256$ cells.*

With square-shaped configurations [Fig. 1(a)–(c)], the grid can hold points up to distances of $64 \times 64$ m, $128 \times 128$ m, and $256 \times 256$ m. For Velodyne HDL-64, which according to the manufacturer specifications can capture points within a range of up to 120 m, the grid size of $128 \times 128$ removes around 3.06% of the points from the point cloud, while the grid of $256 \times 256$ would remove only 0.27% of the points (despite the specification, the dataset still includes a few points outside the range of 128 m). The grid size of $512 \times 512$ keeps all points inside the grid but requires 262144 cells, while $256 \times 256$ and $128 \times 128$ require, respectively, 65536 and 16384 cells. Since in almost every environment the vehicle follows a path/road where the critical information stays in the front and back of the car (points collected on the sides are closer to the sensor due to the road boundaries and geometry), the grid can be further optimized by selecting smaller width values, resulting in fewer resources required to store the point cloud frame under processing. The grid size of $256 \times 128$, represented in Fig. 1(d), provides a good balance between points left outside the grid (0.96%) and the required cells (32768) for the Velodyne HDL-64. However, for a fair evaluation of the algorithm’s performance, the grid size of $512 \times 256$ was selected [Fig. 1(f)], which requires a total number of 131072 cells to store a point cloud frame, and no points are left outside the grid.

### C. Performance

The algorithm was tested for different sequences of the SemanticKITTI dataset (since it provides ground point labels) with a grid size of $512 \times 256$. Fig. 3 provides a visual result of a point cloud frame before and after being processed by the FESTA algorithm using the SemanticKITTI [^27] and Zenseact [^28] datasets. Table V summarizes the performance results for the FESTA algorithm in both the embedded software and embedded hardware implementations, comparing each version with Patchwork [^20], Patchwork++ [^21], and the original algorithm proposed by Anand et al. [^18] on their embedded software version. When comparing FESTA with the work from Anand et al., for all sequences, the results are very similar, which demonstrates that our implementation provides the same results as the original algorithm. This was already expected since the algorithm was only improved in terms of execution performance. Of all the sequences, the one that gives lower scores is Sequence 10, which can be explained by the dynamicity of the environment, and by the fact that in environments with shallow vegetation, the identification of ground points becomes more difficult as the algorithm thresholds are close to the height of nonground objects. With both the software and the hardware versions of FESTA, few points are left outside the grid. For the worst case scenario (FESTA hardware with Sequence 01), the algorithm leaves around 1.08% of the points outside the grid, while for the best-case scenario (FESTA software with Sequence 02), only around 0.02% are discarded from the grid. Nonetheless, these numbers do not affect the overall algorithm performance.

![Figure 9](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t5-3470591-large.gif)

*TABLE V*

![Figure 10](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes3abcd-3470591-large.gif)

*Fig. 3. Point cloud output before and after applying the ground segmentation extension for the tested datasets and sensors. (a) HDL-64 full point cloud. (b) VLS-128 full point cloud. (c) HDL-64 with ground filter. (d) VLS-128 with ground filter.*

Regarding Patchwork and patchwork++, they provide higher Precision ratios for all sequences, which means that of all the points the algorithms identified as ground points, most of them were actually ground points (more than 97% for the best case scenario and 92% for the wort case scenario). However, they also provide the lowest Recall score, which also means that these algorithms do not achieve good success rates in correctly identifying ground points from all the actual ground points (around 94% for the best case scenario and nearly 81% for the worst case scenario). For the remaining metrics, all algorithms behave almost the same.

### D. Processing Time

All algorithms were deployed as an ALFA extension and tested over the ALFA framework, which relies on the ALFA-Node for the point cloud loading, managing, and publishing tasks. Such tasks contribute to the overall processing time and must also be considered. Table VI summarizes the execution performance of all algorithms on their embedded software version, including the hardware version of FESTA, with four different datasets/sensors. The software-only versions assess the execution time of the extensions with and without the steps performed by the ALFA-Node (point cloud loading, Extension processing, and point cloud publishing) and aim at understanding which of the algorithms can provide real-time capabilities when executed on the selected embedded platform. Regarding the hardware version of FESTA, it corresponds to the evaluation of the extension in hardware, including the total processing time with the overhead caused by the ALFA-Node (point cloud loading, point cloud storing in the hardware, hardware extension processing, point cloud loading from the hardware, and point cloud publishing).

![Figure 11](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t6-3470591-large.gif)

*TABLE VI*

#### 1) Velodyne VLP-16:

The FESTA algorithm, deployed in a software-only version, requires a total average time of 8.63 ms to perform the ground segmentation to a point cloud frame. Adding the necessary overhead caused by the ALFA-Node, the total processing time is around 11.67 ms. Compared with the work from Anand et al., which takes around 24.93 ms to process the point cloud frame with a total time of 29.59 ms, this corresponds to an improvement of 188.81% and 153.56%, respectively. Processing the same point cloud frame in hardware takes approximately 2.91 ms, marking a 197.04% improvement over its software version and 757.88% over the original algorithm. However, the overall processing time is around 8.92 ms, corresponding to an improvement of 30.77% over the software version. Despite the algorithm performing faster in hardware, the overhead caused by the ALFA-Node cannot be neglected, which is primarily caused by the storing and loading of the point cloud from the DDR4 memory. For the Patchwork and Patchwork++ algorithms, they require around 29.68 and 43.09 ms to process one frame, respectively.

#### 2) Velodyne HDL-32:

For HDL-32, the FESTA algorithm spends an average time of 13.41 ms to process a point cloud frame, summing up to a total processing time of 18.80 ms. When implementing the extension in hardware, this time is reduced to nearly 4.89 ms (a performance increase of 174.18%), resulting in a total processing time of 14.41 ms (30.46% faster). Compared with the work from Anand et al., this represents an improvement of 632.77% for the algorithm, and 203.82% for the total processing time with the ALFA-Node. Once again, the Patchwork and Patchwork++ algorithms provide the highest time required to process a point cloud frame (around 58.93 and 80.30 ms, respectively).

#### 3) Velodyne HDL-64:

With this sensor, the embedded software implementation of FESTA requires around 50 ms to execute, out of a total time of 64.4 ms (11.68% and 41.14% better than the work from Anand et al., respectively). In contrast, the hardware version takes nearly 13.92 ms (a 259% increase in performance) to process the point cloud, out of the total processing time of 40.87 ms. The Patchwork and Patchwork++ algorithms achieve a processing time of, respectively, 180 and 220.40 ms, failing to provide real-time processing.

#### 4) Velodyne VLS-128:

For VLS-128, the FESTA algorithm spends a processing time of 59.88 ms, summing up to 97.65 ms when accounting for the ALFA-Node. This corresponds, respectively, to an improvement of 203.61% and 139.12%. Processing the extension in hardware takes approximately 18.98 ms, resulting in a total time of 70.59 ms (a 38.33% improvement over the software version and 230.78% over Anand’s algorithm). The work from Anand, as well as the Patchwork and patchwork++ algorithms, fail in providing real-time capabilities, corresponding to a total frame processing time of 233.5, 281.60, and 366.20 ms, respectively.

### E. Hardware Resources

The execution performance improvements achieved by the hardware implementation come at the cost of FPGA resources, which can vary depending on the components selected from the ALFA-Node, the hardware platform, and the grid and cell sizes required to store a point cloud frame. Table VII summarizes the required hardware resources, including Muxes, Flip-Flops (FFs), look-up tables (LUTs), LUT random access memories (LUTRAMs), Block RAMs (BRAMs), and DSP blocks, for deploying the ALFA-Unit alongside the extension with the required setup to interface a Velodyne HDL-64 and a grid size of $512 \times 256$ with a cell size of 0.5 m.

![Figure 12](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t7-3470591-large.gif)

*TABLE VII*

Regardless of the extension deployed in hardware, using the FPGA with the processing system requires 12 Muxes (0.01% from the available resources), 2647 (0.57%) FFs, 2555 (1.11%) LUTs, and 481 (0.47%) LUTRAMs. Deploying the hardware extension requires from the framework one ALFA-Unit alongside its internal modules. The memory management unit (MemMU) requires around 384 (0.19%) Muxes, 4234 (0.92%) FFs, and 632 (0.27%) LUTs, while the monitor unit (MonU) takes 96 (0.05%) Muxes, 768 (0.17%) FFs, and 365 (0.16%) LUTs. For the control unit (CU), around 34 (0.01%) FFs and 1629 (0.71%) LUTs are necessary, while the extension management unit (ExMU) takes 256 (0.13%) Muxes, 6251 (1.36%) FFs, and 592 (0.26%) LUTs. Regarding the FESTA hardware blocks, it requires around 216 (0.11%) Muxes, 735 (0.16%) FFs, 1239 (0.54%) LUTs, and 236 (75.64%) BRAMs. Considering the available resources, the only components that take more than 3% are the BRAMs, which is caused by the required amount of memory that must be allocated in hardware to store a point cloud frame while it is being processed. Other configurations only substantially affect this resource, while other resources remain under 4%.

### F. Power Consumption

The power consumption results were taken from the Power Analysis tool included in the Vivado Design Suite. The tool ran in vectorless mode using the platform constraints for the Zynq UltraScale+ MPSoC, and the power optimizations were disabled. Table VIII provides an overview of both dynamic and static power consumption. Dynamic consumption is influenced by the switching activity of clocks and datapaths, whereas static consumption represents the minimum power required to operate the hardware blocks. Since the time for processing a point cloud frame is known, it is possible to estimate the overall energy consumption.Considering the total power, the ALFA framework dissipates around 3.361 W for a software-only configuration and 3.493 W when deploying the ALFA-Unit with the FESTA Extension in hardware. Regarding the energy required to process one VLP-16 point cloud frame, the platform consumes around 39.22 mJ for the software-only version, while for the hardware this value is reduced to 31.17 mJ. For the HDL-32, the FESTA Extension requires around 63.19 mJ for the software version and 50.33 mJ for its hardware version. Regarding HDL-64, these values rise to 216.65 and 142.76 mJ, respectively. For VLS-128, the software version of the FESTA Extension requires around 328.20 mJ, while the hardware version consumes around 246.57 mJ to process one frame from the point cloud.

![Figure 13](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t8w-3470591-large.gif)

*TABLE VIII*

### G. Discussion

The conducted evaluation of the FESTA algorithm using the ALFA framework demonstrates its significant advantages in deploying ground segmentation algorithms, particularly when leveraging FPGA technology for hardware implementations. Performance-wise, the environment around the car affects the evaluation metrics, as low vegetation and small objects can interfere with the ground points classification. Regarding the execution performance, as the point cloud size increases, the time required to process a point cloud frame also increases, which can be mitigated when deploying hardware accelerators. However, this comes at the cost of resources, as for bigger and high-resolution point clouds the required hardware resources can be highly affected.

Considering that a high-resolution sensor generates a huge amount of data, the execution performance can be further improved if an ROI is applied. Since most of the important data lies in the front of the car (i.e., in the direction of its movement), it is possible to apply cropping regions to the point cloud to reduce the frame size. Following the approach of Roriz et al. [^29], the FESTA algorithm was tested with an ROI of 120° (pointing in the direction of the front of the vehicle), whose results are summarized in Table IX. For VLP-16, the cropping box removes around 17473 (69.51%) points from the point cloud, which further reduces the total processing time of FESTA in hardware from 8.92 to 3.13 ms. Regarding the HDL-32, the cropping box removes around 26023 (62.27%) points from the point cloud, corresponding to a total processing time of 6.29 ms. HDL-64 and VLS-128, for the same scenario, can reduce the execution time from 40.87 to 18.02 and 70.59 to 29.09 ms, respectively.

![Figure 14](https://ieeexplore.ieee.org/mediastore/IEEE/content/media/7361/10752816/10705951/gomes.t9-3470591-large.gif)

*TABLE IX*

## SECTION V. Conclusion

This article presents FESTA, a ground segmentation algorithm based on the approach from Anand et al., deployed on top of the ALFA framework using two setups: a software-based extension and an embedded hardware-accelerated extension deployed in FPGA. Both versions of the algorithm achieved the ground segmentation performance of the original work, while significantly improving the execution time performance, which is mainly possible by exploring FPGA technology present in the hardware platform. The need for hardware acceleration was also proved when using high-resolution sensors, such as the Velodyne VLS-128, where the real-time requirements were still met.

Hereafter, the next steps encompass the study of our algorithm with dynamic elevation thresholds used in the classification step, which can be selected according to the surrounding environment. To enhance the execution performance, the solution can be redesigned to use hardware-based memory blocks instead of using the Xilinx Block Memory Generator IP. This approach would further enhance the parallel processing of several points from the point cloud, which would improve the performance of the Ground Segmentation Core.

## Footnotes

1. https://github.com/alfa-project

## References

[^1]: L. D. Burns, “A vision of our transport future,” Nature, vol. 497, no. 7448, pp. 181–182, May 2013. [DOI](https://doi.org/10.1038/497181a) [Google Scholar](https://scholar.google.com/scholar?as_q=A+vision+of+our+transport+future&as_occt=title&hl=en&as_sdt=0%2C31)

[^2]: Society of Automotive Engineers (SAE), Taxonomy and Definitions for Terms Related to Driving Automation Systems for on-Road Motor Vehicles (Surface Vehicle Recommended Practice: Superseding J3016 Jun 2018), SAE International, Warrendale, PA, USA, Apr. 2021. [DOI](https://doi.org/10.4271/j3016_201609) [Google Scholar](https://scholar.google.com/scholar?as_q=Taxonomy+and+Definitions+for+Terms+Related+to+Driving+Automation+Systems+for+on-Road+Motor+Vehicles+%28Surface+Vehicle+Recommended+Practice%3A+Superseding+J3016+Jun+2018%29&as_occt=title&hl=en&as_sdt=0%2C31)

[^3]: E. Marti, M. A. de Miguel, F. Garcia, and J. Perez, “A review of sensor technologies for perception in automated driving,” IEEE Intell. Transp. Syst. Mag., vol. 11, no. 4, pp. 94–108, Winter 2019. [IEEE](https://ieeexplore.ieee.org/document/8846569) [Google Scholar](https://scholar.google.com/scholar?as_q=A+review+of+sensor+technologies+for+perception+in+automated+driving&as_occt=title&hl=en&as_sdt=0%2C31)

[^4]: J. Jeffs, “Autonomous cars, robotaxis & sensors 2022–2042,” IDTechEx Res., Cambridge, U.K., 2022. [Google Scholar](https://scholar.google.com/scholar?as_q=Autonomous+cars%2C+robotaxis+%26+sensors+2022%E2%80%932042&as_occt=title&hl=en&as_sdt=0%2C31)

[^5]: R. Roriz, J. Cabral, and T. Gomes, “Automotive LiDAR technology: A survey,” IEEE Trans. Intell. Transp. Syst., vol. 23, no. 7, pp. 6282–6297, Jul. 2022. [IEEE](https://ieeexplore.ieee.org/document/9455394) [Google Scholar](https://scholar.google.com/scholar?as_q=Automotive+LiDAR+technology%3A+A+survey&as_occt=title&hl=en&as_sdt=0%2C31)

[^6]: E. Arnold, O. Y. Al-Jarrah, M. Dianati, S. Fallah, D. Oxtoby, and A. Mouzakitis, “A survey on 3D object detection methods for autonomous driving applications,” IEEE Trans. Intell. Transp. Syst., vol. 20, no. 10, pp. 3782–3795, Oct. 2019. [IEEE](https://ieeexplore.ieee.org/document/8621614) [Google Scholar](https://scholar.google.com/scholar?as_q=A+survey+on+3D+object+detection+methods+for+autonomous+driving+applications&as_occt=title&hl=en&as_sdt=0%2C31)

[^7]: S. Shi, X. Wang, and H. Li, “PointRCNN: 3D object proposal generation and detection from point cloud,” in Proc. IEEE/CVF Conf. Comput. Vis. Pattern Recognit. (CVPR), Jun. 2019, pp. 770–779. [IEEE](https://ieeexplore.ieee.org/document/8954080) [Google Scholar](https://scholar.google.com/scholar?as_q=PointRCNN%3A+3D+object+proposal+generation+and+detection+from+point+cloud&as_occt=title&hl=en&as_sdt=0%2C31)

[^8]: Y. Zhou and O. Tuzel, “VoxelNet: End-to-end learning for point cloud based 3D object detection,” in Proc. IEEE/CVF Conf. Comput. Vis. Pattern Recognit., Jun. 2018, pp. 4490–4499. [IEEE](https://ieeexplore.ieee.org/document/8578570) [Google Scholar](https://scholar.google.com/scholar?as_q=VoxelNet%3A+End-to-end+learning+for+point+cloud+based+3D+object+detection&as_occt=title&hl=en&as_sdt=0%2C31)

[^9]: J. Mao, S. Shi, X. Wang, and H. Li, “3D object detection for autonomous driving: A comprehensive survey,” Int. J. Comput. Vis., vol. 131, pp. 1–55, Apr. 2023. [DOI](https://doi.org/10.1007/s11263-023-01790-1) [Google Scholar](https://scholar.google.com/scholar?as_q=3D+object+detection+for+autonomous+driving%3A+A+comprehensive+survey&as_occt=title&hl=en&as_sdt=0%2C31)

[^10]: H. Lee, H. Lee, D. Shin, and K. Yi, “Moving objects tracking based on geometric model-free approach with particle filter using automotive LiDAR,” IEEE Trans. Intell. Transp. Syst., vol. 23, no. 10, pp. 17863–17872, Oct. 2022. [IEEE](https://ieeexplore.ieee.org/document/9733961) [Google Scholar](https://scholar.google.com/scholar?as_q=Moving+objects+tracking+based+on+geometric+model-free+approach+with+particle+filter+using+automotive+LiDAR&as_occt=title&hl=en&as_sdt=0%2C31)

[^11]: N. A. Rawashdeh, J. P. Bos, and N. J. Abu-Alrub, “Camera–LiDAR sensor fusion for drivable area detection in winter weather using convolutional neural networks,” Opt. Eng., vol. 62, no. 3, Oct. 2022, Art. no. 031202. [DOI](https://doi.org/10.1117/1.OE.62.3.031202) [Google Scholar](https://scholar.google.com/scholar?as_q=Camera%E2%80%93LiDAR+sensor+fusion+for+drivable+area+detection+in+winter+weather+using+convolutional+neural+networks&as_occt=title&hl=en&as_sdt=0%2C31)

[^12]: J. Karangwa, J. Liu, and Z. Zeng, “Vehicle detection for autonomous driving: A review of algorithms and datasets,” IEEE Trans. Intell. Transp. Syst., vol. 24, no. 11, pp. 11568–11594, Nov. 2023. [IEEE](https://ieeexplore.ieee.org/document/10196355) [Google Scholar](https://scholar.google.com/scholar?as_q=Vehicle+detection+for+autonomous+driving%3A+A+review+of+algorithms+and+datasets&as_occt=title&hl=en&as_sdt=0%2C31)

[^13]: L. Cunha, R. Roriz, S. Pinto, and T. Gomes, “Hardware-accelerated data decoding and reconstruction for automotive LiDAR sensors,” IEEE Trans. Veh. Technol., vol. 72, no. 4, pp. 4267–4276, Apr. 2023. [IEEE](https://ieeexplore.ieee.org/document/9954909) [Google Scholar](https://scholar.google.com/scholar?as_q=Hardware-accelerated+data+decoding+and+reconstruction+for+automotive+LiDAR+sensors&as_occt=title&hl=en&as_sdt=0%2C31)

[^14]: T. Gomes, D. Matias, A. Campos, L. Cunha, and R. Roriz, “A survey on ground segmentation methods for automotive LiDAR sensors,” Sensors, vol. 23, no. 2, p. 601, Jan. 2023. [DOI](https://doi.org/10.3390/s23020601) [Google Scholar](https://scholar.google.com/scholar?as_q=A+survey+on+ground+segmentation+methods+for+automotive+LiDAR+sensors&as_occt=title&hl=en&as_sdt=0%2C31)

[^15]: W. Huang, “A fast point cloud ground segmentation approach based on coarse-to-fine Markov random field,” IEEE Trans. Intell. Transp. Syst., vol. 23, no. 7, pp. 7841–7854, Jul. 2022. [IEEE](https://ieeexplore.ieee.org/document/9410344) [Google Scholar](https://scholar.google.com/scholar?as_q=A+fast+point+cloud+ground+segmentation+approach+based+on+coarse-to-fine+Markov+random+field&as_occt=title&hl=en&as_sdt=0%2C31)

[^16]: Y. Zhang, J. Wang, X. Wang, and J. M. Dolan, “Road-segmentation-based curb detection method for self-driving via a 3D-LiDAR sensor,” IEEE Trans. Intell. Transp. Syst., vol. 19, no. 12, pp. 3981–3991, Dec. 2018. [IEEE](https://ieeexplore.ieee.org/document/8291612) [Google Scholar](https://scholar.google.com/scholar?as_q=Road-segmentation-based+curb+detection+method+for+self-driving+via+a+3D-LiDAR+sensor&as_occt=title&hl=en&as_sdt=0%2C31)

[^17]: P. Sun, X. Zhao, Z. Xu, R. Wang, and H. Min, “A 3D LiDAR data-based dedicated road boundary detection algorithm for autonomous vehicles,” IEEE Access, vol. 7, pp. 29623–29638, 2019. [IEEE](https://ieeexplore.ieee.org/document/8654619) [Google Scholar](https://scholar.google.com/scholar?as_q=A+3D+LiDAR+data-based+dedicated+road+boundary+detection+algorithm+for+autonomous+vehicles&as_occt=title&hl=en&as_sdt=0%2C31)

[^18]: B. Anand, M. Senapati, V. Barsaiyan, and P. Rajalakshmi, “LiDAR-INS/GNSS-based real-time ground removal, segmentation, and georeferencing framework for smart transportation,” IEEE Trans. Instrum. Meas., vol. 70, pp. 1–11, 2021. [IEEE](https://ieeexplore.ieee.org/document/9558794) [Google Scholar](https://scholar.google.com/scholar?as_q=LiDAR-INS%2FGNSS-based+real-time+ground+removal%2C+segmentation%2C+and+georeferencing+framework+for+smart+transportation&as_occt=title&hl=en&as_sdt=0%2C31)

[^19]: X. Hu, F. S. A. Rodríguez, and A. Gepperth, “A multi-modal system for road detection and segmentation,” in Proc. IEEE Intell. Vehicles Symp., Jun. 2014, pp. 1365–1370. [IEEE](https://ieeexplore.ieee.org/document/6856466) [Google Scholar](https://scholar.google.com/scholar?as_q=A+multi-modal+system+for+road+detection+and+segmentation&as_occt=title&hl=en&as_sdt=0%2C31)

[^20]: H. Lim, M. Oh, and H. Myung, “Patchwork: Concentric zone-based region-wise ground segmentation with ground likelihood estimation using a 3D LiDAR sensor,” IEEE Robot. Autom. Lett., vol. 6, no. 4, pp. 6458–6465, Oct. 2021. [IEEE](https://ieeexplore.ieee.org/document/9466396) [Google Scholar](https://scholar.google.com/scholar?as_q=Patchwork%3A+Concentric+zone-based+region-wise+ground+segmentation+with+ground+likelihood+estimation+using+a+3D+LiDAR+sensor&as_occt=title&hl=en&as_sdt=0%2C31)

[^21]: S. Lee, H. Lim, and H. Myung, “Patchwork++: Fast and robust ground segmentation solving partial under-segmentation using 3D point cloud,” in Proc. IEEE/RSJ Int. Conf. Intell. Robots Syst. (IROS), Oct. 2022, pp. 13276–13283. [IEEE](https://ieeexplore.ieee.org/document/9981561) [Google Scholar](https://scholar.google.com/scholar?as_q=Patchwork%2B%2B%3A+Fast+and+robust+ground+segmentation+solving+partial+under-segmentation+using+3D+point+cloud&as_occt=title&hl=en&as_sdt=0%2C31)

[^22]: A. Josyula, B. Anand, and P. Rajalakshmi, “Fast object segmentation pipeline for point clouds using robot operating system,” in Proc. IEEE 5th World Forum Internet Things (WF-IoT), Apr. 2019, pp. 915–919. [IEEE](https://ieeexplore.ieee.org/document/8767255) [Google Scholar](https://scholar.google.com/scholar?as_q=Fast+object+segmentation+pipeline+for+point+clouds+using+robot+operating+system&as_occt=title&hl=en&as_sdt=0%2C31)

[^23]: R. B. Rusu and S. Cousins, “3D is here: Point cloud library (PCL),” in Proc. IEEE Int. Conf. Robot. Autom., May 2011, pp. 1–4. [IEEE](https://ieeexplore.ieee.org/document/5980567) [Google Scholar](https://scholar.google.com/scholar?as_q=3D+is+here%3A+Point+cloud+library+%28PCL%29&as_occt=title&hl=en&as_sdt=0%2C31)

[^25]: R. Kelley. ( 2023 ). Self-Driving Lincoln Mkz Snow Dataset. Accessed: Oct. 19, 2023. [Online]. Available: https://richardkelley.io/data [Google Scholar](https://scholar.google.com/scholar?as_q=Self-Driving+Lincoln+Mkz+Snow+Dataset&as_occt=title&hl=en&as_sdt=0%2C31)

[^26]: J. Morales, R. Vázquez-Martín, A. Mandow, D. Morilla-Cabello, and A. García-Cerezo, “The UMA-SAR Dataset: Multimodal data collection from a ground vehicle during outdoor disaster response training exercises,” Int. J. Robot. Res., vol. 40, nos. 6–7, pp. 835–847, 2021. [DOI](https://doi.org/10.1177/02783649211004959) [Google Scholar](https://scholar.google.com/scholar?as_q=The+UMA-SAR+Dataset%3A+Multimodal+data+collection+from+a+ground+vehicle+during+outdoor+disaster+response+training+exercises&as_occt=title&hl=en&as_sdt=0%2C31)

[^27]: J. Behley, “Towards 3D LiDAR-based semantic scene understanding of 3D point cloud sequences: The SemanticKITTI dataset,” Int. J. Robot. Res., vol. 40, nos. 8–9, pp. 959–967, Aug. 2021. [DOI](https://doi.org/10.1177/02783649211006735) [Google Scholar](https://scholar.google.com/scholar?as_q=Towards+3D+LiDAR-based+semantic+scene+understanding+of+3D+point+cloud+sequences%3A+The+SemanticKITTI+dataset&as_occt=title&hl=en&as_sdt=0%2C31)

[^28]: M. Alibeigi, “Zenseact open dataset: A large-scale and diverse multimodal dataset for autonomous driving,” in Proc. IEEE/CVF Int. Conf. Comput. Vis. (ICCV), Paris, France, 2023, pp. 20121–20131, doi: 10.1109/ICCV51070.2023.01846. [IEEE](https://ieeexplore.ieee.org/document/10378272) [Google Scholar](https://scholar.google.com/scholar?as_q=Zenseact+open+dataset%3A+A+large-scale+and+diverse+multimodal+dataset+for+autonomous+driving&as_occt=title&hl=en&as_sdt=0%2C31)

[^29]: R. Roriz, A. Campos, S. Pinto, and T. Gomes, “DIOR: A hardware-assisted weather denoising solution for LiDAR point clouds,” IEEE Sensors J., vol. 22, no. 2, pp. 1621–1628, Jan. 2022. [IEEE](https://ieeexplore.ieee.org/document/9643022) [Google Scholar](https://scholar.google.com/scholar?as_q=DIOR%3A+A+hardware-assisted+weather+denoising+solution+for+LiDAR+point+clouds&as_occt=title&hl=en&as_sdt=0%2C31)

### Additional References