FESTA：FPGA 加速的汽车激光雷达地面分割技术

摘要

汽车行业正快速推进更智能、更安全、更可持续的自动驾驶车辆的研发。如今，这些车辆配备了先进的驾驶辅助系统 (ADAS)，其中包括复杂的感知技术以安全地导航环境。感知系统中的关键传感器之一是激光雷达 (LiDAR)。它可以精确测量物体的距离，并生成周围环境的详细实时 3-D 地图，包括障碍物和道路边界。提取道路信息以识别可行驶区域是对 LiDAR 输出执行的最重要步骤之一；然而，由于高分辨率传感器产生的数据量巨大，这项任务变得相当具有挑战性。本文提出了 FESTA，一种在现场可编程门阵列 (FPGA) 上使用 ALFA 框架加速的地面分割技术，能够实时执行应用于传感器输出的地面分割步骤。评估结果显示，FESTA 处理来自 VLP-16 传感器的点云帧平均耗时 8.92 ms，HDL-32 为 14.41 ms，HDL-64 为 40.87 ms，VLS-128 为 70.59 ms，同时在其他性能指标上优于最先进的算法。

作者

José Carvalho Centro ALGORITMI/LASI, Universidade do Minho-Campus Azurém, 吉马良斯, 葡萄牙

Luís Cunha Centro ALGORITMI/LASI, Universidade do Minho-Campus Azurém, 吉马良斯, 葡萄牙 ORCID: 0009-0008-6762-8018

Sandro Pinto Centro ALGORITMI/LASI, Universidade do Minho-Campus Azurém, 吉马良斯, 葡萄牙 ORCID: 0000-0003-4580-7484

Tiago Gomes Centro ALGORITMI/LASI, Universidade do Minho-Campus Azurém, 吉马良斯, 葡萄牙 ORCID: 0000-0002-4071-9015

出版信息

期刊： IEEE Sensors Journal 年份： 2024 卷号： 24 期号： 22 页码： 38005-38014 DOI： 10.1109/JSEN.2024.3470591 文章编号： 10705951 ISSN： Print ISSN: 1530-437X, Electronic ISSN: 1558-1748, CD: 2379-9153

指标

论文引用数： 5 总下载量： 327

资助

• 科学技术基金会（FCT）在研究与发展单位项目范围内（拨款：UIDB/00319/2020 和 2023.01007.BD）

关键词

IEEE 关键词： 传感器, 点云压缩, 道路, 激光雷达, 实时系统, 汽车工程, 预测算法, 准确性, 硬件, 拟合

光检测与测距, 地面段, 性能指标, 点云, 自动驾驶车辆, 汽车工业, 感知系统, 高级驾驶辅助系统, 高分辨率传感器, 实时输出, 道路边界, 单元尺寸, 处理时间, 算法性能, 交并比, 案例场景, 网格尺寸, 查找表, 地面平面, 总处理时间, 地面点, 资源成本, 硬件加速器, 点云处理, 最小高度, 硬件实现, 随机样本一致性, 硬件资源, 点云数据

作者关键词： 自动驾驶车辆, 嵌入式系统, 现场可编程门阵列 (FPGA), 地面分割, 激光检测与测距 (LiDAR), 感知系统

未定义

第 I 节. 引言

多年来，汽车行业一直面临着几项重要的技术革命，这些革命对全球社会和出行产生了深远影响¹。虽然从燃油发动机向电动发动机的转变是本十年最重要的变革之一，但实现完全驾驶自动化的目标仍持续吸引着研究和产业界的关注。根据 SAE International 的定义，车辆自动化可分为六个等级²，其中 0–2 级需要驾驶员交互和对车辆的监控，3–5 级则引入使车辆能够在整个驾驶场景中自主运行的功能。如今大多数现代车辆已能够提供 2 级功能，这包括依赖不同传感器技术数据的改进型高级驾驶辅助系统（ADAS），以实现对车辆周围环境的高效感知并辅助驾驶任务³、⁴。

在感知系统中，所有传感器中，激光雷达（LiDAR）以其测距精确、能够在几乎所有光照条件下创建详细的三维点云而脱颖而出⁵。这些功能可帮助自动驾驶车辆执行多项任务，例如障碍物检测、识别、规避⁶、⁷、⁸、⁹、¹⁰，以及道路与地面识别以实现车辆导航¹¹、¹²。然而，为了高效完成这些任务，LiDAR 必须实时提供高分辨率的点云，这反过来又增加了数据传输量和后续处理系统的负荷¹³。

一种著名的减少待处理点云大小的技术是数据分割 ¹⁴，它包括从剩余数据中识别并分离特定点。该步骤的输出是一个新的点云，可用于不同的任务。虽然在去除地面点后物体识别和分类可以表现更好，但如果仅处理地面数据，路面导航任务可能会表现更好。尽管如此，执行地面分割步骤可能会消耗计算资源，因为高分辨率点云往往需要稳健的处理系统和足够的内存来实现实时执行 ¹⁵。此外，在汽车场景中，大多数处理平台都是具有资源约束的嵌入式系统，这限制了这些算法在传感器附近的使用。

本文介绍了 FESTA，一种借助现场可编程门阵列（FPGA）技术为汽车应用中的 LiDAR 传感器提供的地面分割技术。本文的主要贡献包括：1）一种针对汽车 LiDAR 传感器的基于硬件的地面分割算法；2）对算法主要步骤、在 ALFA 框架中的实现以及其所有主要组件和关键特性的详细概述；3）对所提出解决方案的全面评估与基准测试。

第二节. LiDAR 地面分割

自动驾驶车辆的地面分割是过去几年内被广泛研究的课题。文献中现有的地面分割方法可分为五大类 ¹⁶，其复杂程度从需要高算力的复杂算法到能够实现实时要求的更为简易实现各不相同。实时特性、计算需求与整体算法性能之间的权衡决定了是否应优先采用某一类方法。对于具备实时需求的自动驾驶应用，基于平面拟合的方法能够在复杂度与整体算法性能之间取得良好平衡 ¹⁷。该方法的核心在于将地面几何转换为单一平面或一组平面网格：给定一组点后，识别使点与平面之间正交距离最小的平面。随后，将每个点的距离与不同阈值比较，以识别并标记地面数据。

表 I 总结了最先进的平面拟合算法，并从复杂度、处理所选数据集点云帧所需时间以及精度（Precision）、召回率（Recall）和 F1-score 等性能指标进行比较。虽然精确率（Accuracy）和交并比（Intersection over Union，IoU）同样用于评估性能，但当前文献并未提供这些指标。所有这些指标均取决于真阳性（TP）、真阴性（TN）、假阳性（FP）和假阴性（FN）的预测值。它们用于评估算法正确检测和标记/去除点云中地面点的能力。精度（1）表示所有地面点中被正确检测出的地面点数，而召回率（2）衡量在点云中被正确检测出的地面点数。F1-score（3）通过两者的调和平均值提供精度与召回率的综合信息，准确率表示正确预测点占总点数的比例（4）。最后，IoU 表示预测与真实地面区域重叠面积与其并集面积之比（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*}

表 I

所有在表 I 中总结的实现已在城市汽车场景中进行了测试。虽然测试是在不同条件下进行的——不同的数据集和设置——但仍然可以在不考虑所使用硬件的情况下评估它们的准确性。在作者为评估收集数据集的情况下 ¹⁸、¹⁹、²⁰，结果保持可比性，因为它们反映了现实世界场景。然而，处理时间高度依赖于多个因素：算法的复杂度、所使用的 LiDAR 传感器以及用于运行算法的计算系统。

Hu 等人 ²¹ 提出了基于随机采样一致性（RANSAC）算法的平面拟合方法。它使用短期记忆技术来解决预测地面平面时的精度问题，但这种方法会增加算法的复杂度，导致从 KITTI Vision Benchmark Suite 数据集处理单个点云帧约需要 600 毫秒。除非能提供实时性能外，该方法主要在平坦表面上表现良好，获得了最低的 F1-分数，可能是由于假设只有一个地面平面。Zhang 等人 ²² 也提出了一种基于 RANSAC 算法的方法。该方法在实际场景中实现了 12 毫秒的帧处理时间，车辆行驶 2.9 公里，平均速度 28.6 公里/小时。然而，F1-分数仍然是最低之一。此外，斑马线检测算法在存在障碍物时失败，导致整体性能下降。

Sun 等人 ²³ 提出了一种在真实场景中测试的方法，取得了实时性能，帧处理时间为36.5毫秒，且准确率良好。评估包括四种不同的道路类型：直线城市道路、曲折道路、宽度不一且有路缘石的道路，以及低矮边界的道路。虽然该方法与张等人 ²⁴ 提出的工作相似，但取得的结果略好。这主要归因于实现了一种即使视野受阻也能估计道路边界的功能。这提高了在多种道路条件下的适应性，并作为对障碍物的预防措施。然而，该方法在交叉口估计道路边界时经常失败，这在路缘检测算法中是常见的问题。Lim 等人 ²⁵ 提出了 Patchwork，这是一种基于主成分分析（PCA）而非 RANSAC 算法的平面拟合方法，得到更简单但更快的解决方案。除 PCA 外，它还包括一个地面似然估计（GLE）步骤，以提高精度并增强算法对欠分割的免疫力。然而，地面平面有时会出现不连续，这归因于相邻箱子（即极坐标网格地图细分元素）之间缺乏交互。这导致在提取接近地面的物体时变得更困难。

Lee 等人 ²⁶ 改进了 Patchwork 并开发了 Patchwork++，该方法利用自适应 GLE（A-GLE）根据先前的地面分割结果动态计算合适的参数。此外，Patchwork++ 通过采用时空地面回退（TGR）来解决部分欠分割问题，该方法利用临时地面属性。还引入了区域分段竖直平面拟合（R-VPF），即使地面以不同层次升高也能正确分割地面平面。Patchwork++ 也在 SemanticKITTI 数据集上进行了测试，处理一帧点云需要约 18.23 毫秒，精度（Precision）为 94.92%，召回率（Recall）为 98.18%，并且 F1‑score 为 96.51%。Josyula 等人 ²⁷ 提出了另一种基于 RANSAC 算法的方法。使用 KITTI Vision Benchmark Suite 数据集进行测试时，该方法能够实现实时性能，虽然未公布其他性能指标。Anand 等人 ²⁸ 用自己的数据集进行了测试，该方法在所有其他方法中获得了最佳精度结果。然而，召回率相对较低。

最终，Anand 等人 ²⁹ 提出的工作通过使用各种数据集和计算设置进行了全面评估。当在他们自己的数据集上测试时，召回率为 99.49%，F1‑score 为 99.54%。然而，该数据集并未全面代表驾驶场景。尽管如此，在 Paris‑Lille 3‑D 数据集上，该算法取得了 98.69% 的精度（Precision）、97.96% 的召回率（Recall）以及 98.32% 的 F1‑score，证明了算法的有效性。列表中排名第二的最佳处理时间是在 KITTI 数据集上实现的，对应处理一帧点云需要 12.69 毫秒。然而，所使用的计算系统无疑是最强大的。当在硬件资源较低的平台（NVIDIA Jetson TX2）和使用 Velodyne VLP‑32 记录的数据集上测试时，帧处理时间约为 37.03 毫秒。尽管在真实世界数据集上呈现出最佳性能结果，但在高分辨率传感器上实现实时要求可能会成为一项艰巨任务，即使使用更强大的设置。

针对具备加速能力的嵌入式平台，所提出的 FESTA 算法遵循 Anand 等人提出的工作 ³⁰。其主要目标是在保持其他性能指标的前提下，降低整体帧处理时间，以支持高分辨率传感器。与原始工作相比，主要区别包括：1）使用固定尺寸的单元格网格，减少算法的一步并节省嵌入式平台的硬件资源；2）为地面分类步骤设定新的阈值；3）支持硬件加速器，实现实时性能，即使在使用高分辨率传感器时亦可。

第三节. FESTA：设计与实现

A. 设计

FESTA 提议使用固定尺寸的单元格网格以降低执行时间。该固定几何结构改善了执行时间，并使算法能够在硬件受限的嵌入式平台上部署，而无需分配不必要的资源。与原始版本不同，我们的算法只需要两步即可完成地面分割、网格创建和地面点分类。

1) 网格创建:

构建单元格网格仅需一次遍历点云帧，正如算法 1 所述。要填充网格，首先需要以单元格数量来定义其宽度和长度，这直接与传感器的范围和分辨率相关，并且在部署前必须进行调优。随后，单元格的尺寸与网格分辨率直接相关，也必须考虑。例如，设计一个单元格网格为 128 \times 128 个单元格 [长度 \times 宽度]，单元格尺寸为 0.5 m，得到的网格覆盖面积为 64 \times 64 m。将单元格尺寸增大至 1 m 将把范围提升至 128 \times 128 m，但会降低最终网格的分辨率，可能影响性能结果。固定尺寸的单元格网格有助于在计算资源受限或需要高效管理的场景中改进资源规划和分配，例如硬件加速器。

算法 1 FESTA：网格创建算法

每个单元格可以直接使用单个地址访问，\text {cell}_{\text {index}}，而不是同时使用 \text {cell}_{x} 和 \text {cell}_{y}，从而实现更高效的内存访问。 这些地址是通过对 X-和 Y-坐标进行归一化来生成的，以创建以 (0, 0) 为原点的网格——使用算法1中第6和第7行的表达式。 这消除了由负坐标引起的问题，并允许连续的内存地址分配。 计算 \text {cell}_{x} 和 \text {cell}_{y} 是通过取归一化后的 X 和 Y 值以及为网格选择的单元格大小来完成的——使用算法1中第8和第9行的表达式。 访问单元格是使用第11行的表达式完成的，该表达式使用归一化后的 X 和 Y 值以及网格宽度来根据 \text {cell}_{x} 和 \text {cell}_{y} 创建单个地址。 网格中的单元格按行主序索引，尽管算法的行为不受所选顺序的影响。 然而，只有当点位于网格的周边以内时，才执行此步骤。

位于网格边界之外的点，即距离传感器更远的点，将被丢弃，不再进一步处理。 在汽车环境中，并考虑到更远距离点云的稀疏性，远距离点很可能被视为噪声，且不适合用来表示任何相关物体或障碍物。 因此，如果网格尺寸足够且丢弃点的数量最小，则可以在性能与资源利用之间实现良好的折衷。

2) 地面分割:

地面分类步骤（算法 2）始于在每个单元格内检索最小和最大 Z 值，这些值是在网格创建阶段计算得到的。通过利用它们的垂直分布，可以有效地识别出地面水平点。一个单元格仅在包含点且其最小高程 (\text {z}_{\min }) 落低于高程阈值 \zeta 时才符合地面移除条件。这可防止仅包含更高高程点的单元格被错误分类为地面。接下来计算 \text {z}_{\text {sub}}，其对应于每个单元格最大 (\text {z}_{\max }) 与最小 (\text {z}_{\min }) 高程之差。如果该差值高于高程阈值 \epsilon（表明单元格内存在显著高程变化），则所有落在 \text {z}_{\min } 以内且距离阈值为 \text {z}_{\min } + \delta 的点被归类为地面。最后，在 \text {z}_{\text {sub}} 低于 \epsilon 的情形下，这些点可能对应于该单元格内的小物体。在此类情况下，所有 Z 值低于 \text {z}_{\min } + \text {z}_{\text {th}} 的点被归类为地面，其中 \text {z}_{\text {th}} 取 \text {z}_{\text {sub}} 除以分数 f（算法 2，第 6 行）的值。该参数 f 确保在识别地面点时仅考虑 \text {z}_{\text {sub}} 的一部分。通过调整其值，可调节分类过程的灵敏度，从而保留小物体在点云中。

算法 2 FESTA：地面分类步骤

所有这些参数和阈值，\zeta、\epsilon、\delta、f 和 \text {cell}_{\text {size}}，可根据传感器和驾驶环境进行自定义，以调节算法行为。 此外，与原方法相反，分类通过顺序处理点云帧中的所有点来完成，这显著提高了吞吐量并降低了与随机内存访问相比的延迟。 这些改进与固定尺寸网格相结合，有助于实现更好的执行性能比。

B. 架构

FESTA 被部署在 ALFA 框架上，[^24] 这是一个面向原型、实现和验证基于 LiDAR 的自主应用算法的开源工具。其架构如图 1 所示，支持不同的开发环境，例如桌面和嵌入式平台，包括带有 FPGA 的平台，用于开发自定义加速器以处理点云数据。软件层运行在支持 ROS2 的 Linux 发行版系统上，便于与其他 ROS2 应用或第三方库（如点云库 PCL）³¹ 的集成。该框架还包含 ALFA-Monitor 工具，用于可视化点云数据、配置扩展参数以及监控用户自定义指标。

图 1. FESTA 系统架构.

在桌面或嵌入式环境中开发和运行任何扩展的基础是 ALFA-Node，它是基于 ROS2 的组件，负责接收传感器数据、执行点云处理算法、将处理后的点云发布给其他应用程序并配置扩展。其硬件对应体 ALFA-Unit 负责容纳硬件加速器，以支持算法中最耗时的步骤。软件和硬件的协同设计使组件能够通过如 AXI4 等 AMBA 通信总线无缝通信。使用该框架开发了三种 FESTA 算法版本：(1) 基于桌面的软件扩展，用于验证性能并将算法与 Anand 等人提出的原始方案进行比较 ³²、Patchwork ³³ 和 Patchwork++ ³⁴；(2) 嵌入式软件版本，用以评估执行性能瓶颈；(3) 最后，在 FPGA 上部署的硬件加速扩展，以提高执行性能同时保持整体性能指标。

C. 软件实现

与 ALFA-Node 的集成使 FESTA 扩展能够接收和发布点云，通过 ROS2 配置服务（在 ALFA-Monitor 中使用）更改参数，并传输地面分割性能指标以及扩展的实时状态。FESTA 扩展使用表 II 中的参数值部署，包括网格尺寸（宽度 \times 长度）、单元尺寸，以及分类阈值：\zeta、\epsilon、\delta 和 f。

表 II

D. 硬件实现

硬件实现包括 ALFA 框架已提供的若干 IP 块用于处理扩展，以及为实现 FESTA 算法而开发的新硬件块。该加速器包含两个基本块：1）Cell Grid Core，负责创建和填充网格。在接收到新的点云后，它将点分配到各自的单元格并计算分类步骤的阈值；2）Ground Segmentation Core，用于将点分类为地面或非地面。虽然某些步骤需要顺序执行，但利用硬件方案的优势，FESTA 采用完全流水线处理以提高效率并增加吞吐量，确保计算资源得到最优利用。此外，FESTA 架构部署了两个 BRAM 块，用于临时存储点云并管理点分类所需的必要信息。Grid BRAM 存储每个单元格及其对应点的信息，包括该单元格的最小和最大 Z 坐标；而 Points BRAM 存储分割所需的个别点信息，例如 Z 坐标和 \text {cell}_{\text {index}}，后者对应于指向 Grid BRAM 中对应单元格地址的逻辑指针。

第四节 评估

A. 评估设置

FESTA算法在三种ALFA开发环境中进行了评估：桌面环境、嵌入式软件环境以及带硬件加速支持的嵌入式软件环境。桌面计算机配备了AMD Ryzen 6800 HS处理器，8个CPU核心，主频为3.2 GHz，内存16 GB。ALFA框架运行在Ubuntu 22.04.3 LTS Linux发行版上，使用PCL 1.12.1版本和ROS2 Humble发行版。嵌入式环境使用了ZCU104评估套件，配备Zynq UltraScale+ MPSoC。该MPSoC包含四核Arm Cortex-A53应用处理器、双核Cortex-R5实时处理器，以及配备504K系统逻辑单元和1728个数字信号处理（DSP）切片的FPGA技术，并支持2 GB DDR4内存。

评估重点关注FESTA算法在不同网格和单元尺寸以及不同点云感兴趣区域（ROI）下的性能。它使用了不同的公开数据集（如表III所示），从四个Velodyne LiDAR传感器在不同环境中获取数据：

1. 自驾Lincoln MKZ数据集 ³⁵，该数据集包含来自Velodyne VLP-16的扫描数据，共573帧，帧率为10 Hz，每帧平均约有25138个点。

2. 来自UMA-SAR数据集 ³⁶ 的序列2018-07-25-11-25-10，记录了一辆配备Velodyne HDL-32的地面车辆，在非城市户外环境中自主移动。该数据集包含2944帧，帧率为10 Hz，每帧平均点云大小为41794个点。

3. 来自SemanticKITTI数据集 ³⁷ 的序列00（4541帧，121494点/帧）、01（1101帧，105682点/帧）、02（4661帧，105682点/帧）、06（1101帧，122300点/帧）以及10（1201帧，125910点/帧），该数据集记录了一辆配备Velodyne HDL-64、以10 Hz速度通过不同环境的车辆。

4. 来自Zenseact数据集 ³⁸ 的Drives序列000000，该序列使用Velodyne VLS-128在高速公路上记录，车流繁忙，共2859帧，帧率为10 Hz，平均每帧206612个点。

表 III

算法的性能评估指标包括：1) Precision (1); 2) Recall (2); 3) F1-score (3); 4) Accuracy (4); and 5) the IoU (5)。为更好地理解哪些网格/单元尺寸值更适合给定传感器，还指出了留在所选网格之外的点数。除此之外，还分析了嵌入式软件和硬件加速器的执行性能以及所需的 FPGA 资源。

B. 网格尺寸与单元尺寸

网格大小是根据所选传感器/数据集静态选择的。此步骤的主要目标是在尽可能多的点保留在网格内的同时，避免为空单元分配不必要的资源。图 2 显示了 0.5 m 单元格尺寸的不同配置，而表 IV 总结了使用 SemanticKITTI 数据集 Seq. 00 对不同单元格尺寸（0.25、0.5 和 1 m）的部分已选择设置。使用 0.25 m 的单元格尺寸需要更大的网格尺寸（会增加组织和存储点云帧所需资源以及算法执行时间），而 1 m 的单元格尺寸有助于节省资源和执行时间，但会降低算法性能，因为包含更多点的单元格更容易错误分类为地面/非地面单元格。因此，并且与 Anand 等人的工作 ³⁹ 一致，最优的单元格尺寸为 0.5 m。

表 IV

图 2. 不同网格尺寸，单元尺寸为 0.5 m，适用于 Velodyne HDL-64. (a) 网格包含 128\times 128 个单元格. (b) 网格包含 256\times 256 个单元格. (c) 网格包含 512\times 512 个单元格. (d) 网格包含 256\times 128 个单元格. (e) 网格包含 512\times 128 个单元格. (f) 网格包含 512\times 256 个单元格.

使用方形配置 [图 1(a)–(c)]，网格可以容纳距离为 64 \times 64 米、128 \times 128 米和 256 \times 256 米的点。对于 Velodyne HDL-64，依据制造商规格能够捕获最大 120 米范围内的点，网格尺寸为 128 \times 128 时会从点云中去除约 3.06% 的点，而尺寸为 256 \times 256 的网格仅去除 0.27% 的点（尽管规格如此，数据集仍包含少量超出 128 米范围的点）。网格尺寸为 512 \times 512 时，所有点均在网格内，但需要 262144 个单元，而 256 \times 256 和 128 \times 128 分别需要 65536 和 16384 个单元。由于在几乎所有环境中，车辆沿着路径/道路行驶，关键信息位于车辆前后（侧面采集的点由于道路边界和几何关系更接近传感器），网格可以通过选择更小的宽度值进一步优化，从而减少存储点云帧时所需的资源。网格尺寸为 256 \times 128（如图 1(d) 所示）在网格外残留点（0.96%）和所需单元（32768）之间提供了良好的平衡，适用于 Velodyne HDL-64。然而，为了公平评估算法性能，选择了网格尺寸为 512 \times 256（如图 1(f) 所示），该尺寸需总共 131072 个单元来存储点云帧，且没有点残留在网格之外。

C. 性能

该算法在 SemanticKITTI 数据集的不同序列上进行了测试（因为它提供地面点标签），网格大小为 512 \times 256。图 3 显示了使用 SemanticKITTI ⁴⁰ 和 Zenseact ⁴¹ 数据集的 FESTA 算法处理前后点云帧的可视化结果。表 V 总结了 FESTA 算法在嵌入式软件和嵌入式硬件实现中的性能结果，并将每个版本与 Patchwork ⁴²、Patchwork++ ⁴³ 以及 Anand 等人提出的原始算法（他们的嵌入式软件版本 ⁴⁴）进行比较。在将 FESTA 与 Anand 等人的工作进行比较时，所有序列的结果都非常相似，证明我们的实现与原始算法得到相同的结果。这本来就是预期的，因为该算法仅在执行性能方面得到改进。在所有序列中，得分最低的是序列 10，这可以通过环境的动态性以及在浅层植被环境中，地面点的识别变得更加困难来解释，因为算法阈值接近非地面对象的高度。无论是 FESTA 的软件还是硬件版本，离开网格的点数都很少。在最坏情况（FESTA 硬件与序列 01）下，算法约有 1.08% 的点落在网格之外；而在最佳情况（FESTA 软件与序列 02）下，约 0.02% 的点被丢弃。 然而，这些数字并未影响整体算法性能。

表V

图 3. 对测试数据集和传感器应用地面分割扩展前后点云输出的可视化。 (a) HDL-64 全点云。 (b) VLS-128 全点云。 (c) HDL-64 加地面滤波。 (d) VLS-128 加地面滤波。

关于 Patchwork 和 patchwork++，它们为所有序列提供更高的精准率，这意味着在所有被算法识别为地面点的点中，大多数实际上是地面点（最佳情况超过97%，最差情况为92%）。然而，它们也给出了最低的召回率，这同样意味着这些算法在正确识别所有实际地面点方面的成功率不高（最佳情况约94%，最差情况近81%）。其余指标上，所有算法的表现几乎相同。

D. 处理时间

所有算法都作为 ALFA 扩展部署，并在 ALFA 框架上进行测试，ALFA 框架依赖 ALFA-Node 进行点云加载、管理和发布任务。此类任务会影响整体处理时间，也需要考虑。表 VI 概述了所有算法在其嵌入式软件版本上的执行性能，包括 FESTA 的硬件版本，并涉及四个不同的数据集/传感器。仅软件版本评估了在有无 ALFA-Node 执行的步骤（点云加载、扩展处理和点云发布）情况下扩展的执行时间，旨在了解哪些算法在所选嵌入式平台上能提供实时能力。关于 FESTA 的硬件版本，它对应于硬件中的扩展评估，包括由 ALFA-Node 引起的总处理时间（点云加载、在硬件中存储点云、硬件扩展处理、从硬件加载点云以及点云发布）。

表 VI

1) Velodyne VLP-16:

FESTA算法在仅软件版本下，对点云帧进行地面分割，平均总耗时为 8.63 毫秒。加入 ALFA-Node 带来的必要开销后，总处理时间约为 11.67 毫秒。与 Anand 等人的工作相比，该工作处理点云帧耗时约 24.93 毫秒，总时间为 29.59 毫秒，分别对应 188.81% 和 153.56% 的提升。在硬件上处理同一点云帧约需 2.91 毫秒，较软件版本提升 197.04%，较原始算法提升 757.88%。然而，整体处理时间约为 8.92 毫秒，相比软件版本提升 30.77%。尽管算法在硬件上运行更快，但 ALFA-Node 带来的开销不容忽视，主要由将点云存储和加载到 DDR4 内存造成。对于 Patchwork 和 Patchwork++ 算法，它们分别需要约 29.68 毫秒和 43.09 毫秒来处理一帧。

2) Velodyne HDL-32:

对于 HDL-32，FESTA算法平均耗时 13.41 毫秒处理一帧点云，合计总处理时间为 18.80 毫秒。在硬件实现扩展后，该时间降至约 4.89 毫秒（性能提升 174.18%），总处理时间为 14.41 毫秒（快 30.46%）。与 Anand 等人的工作相比，算法提升 632.77%，在 ALFA-Node 的总处理时间上提升 203.82%。再次，Patchwork 和 Patchwork++ 算法分别需要约 58.93 毫秒和 80.30 毫秒来处理一帧点云，耗时最高。

3) Velodyne HDL-64:

使用此传感器时，嵌入式软件实现的 FESTA 需要约 50 毫秒执行，合计总时间为 64.4 毫秒，分别比 Anand 等人的工作好 11.68% 和 41.14%。相反，硬件版本处理点云耗时约 13.92 毫秒（性能提升 259%），总处理时间为 40.87 毫秒。Patchwork 和 Patchwork++ 算法分别耗时 180 毫秒和 220.40 毫秒，未能实现实时处理。

4) Velodyne VLS-128:

对于 VLS-128，FESTA 算法的处理时间为 59.88 毫秒，计入 ALFA-Node 后累计为 97.65 毫秒。分别对应 203.61% 和 139.12% 的提升。将扩展模块硬件化处理约耗时 18.98 毫秒，总时间为 70.59 毫秒（相较软件版本提升 38.33%，相较 Anand 算法提升 230.78%）。Anand 的工作，以及 Patchwork 和 patchwork++ 算法无法提供实时能力，分别对应总帧处理时间 233.5、281.60 和 366.20 毫秒。

E. 硬件资源

硬件实现所带来的执行性能提升需要以 FPGA 资源为代价，这些资源会因所选的 ALFA-Node 组件、硬件平台以及用于存储点云帧所需的网格与单元尺寸而有所不同。表 VII 总结了部署 ALFA-Unit 与扩展模块所需的硬件资源，包括 Muxes、Flip-Flops (FFs)、查找表 (LUTs)、LUT 随机存取内存 (LUTRAMs)、块 RAM (BRAMs) 和 DSP 块，满足与 Velodyne HDL-64 接口并使用网格大小为 512 \times 256、单元大小为 0.5 m 的所需设置。

表 VII

无论在硬件中部署何种扩展，使用 FPGA 与处理系统需要 12 Muxes（占可用资源的 0.01%），2647 (0.57%) FFs，2555 (1.11%) LUTs，和 481 (0.47%) LUTRAMs。部署硬件扩展需要框架中的一个 ALFA-Unit 以及其内部模块。内存管理单元（MemMU）需要大约 384 (0.19%) Muxes，4234 (0.92%) FFs，和 632 (0.27%) LUTs，而监视单元（MonU）使用 96 (0.05%) Muxes，768 (0.17%) FFs，和 365 (0.16%) LUTs。对于控制单元（CU），大约需要 34 (0.01%) FFs 和 1629 (0.71%) LUTs，而扩展管理单元（ExMU）使用 256 (0.13%) Muxes，6251 (1.36%) FFs，和 592 (0.26%) LUTs。关于 FESTA 硬件块，它需要大约 216 (0.11%) Muxes，735 (0.16%) FFs，1239 (0.54%) LUTs，和 236 (75.64%) BRAMs。考虑到可用资源，唯一占用超过 3% 的组件是 BRAMs，这是由于必须在硬件中分配所需的内存量来存储正在处理的点云帧所致。其他配置只会显著影响此资源，而其他资源仍低于 4%。

F. 功耗

功耗结果来自 Vivado Design Suite 中包含的 Power Analysis 工具。该工具在无向量模式下使用 Zynq UltraScale+ MPSoC 的平台约束运行，并禁用了功耗优化。表 VIII 概述了动态功耗和静态功耗。动态功耗受时钟和数据路径切换活动的影响，而静态功耗代表了运行硬件块所需的最小功率。由于已知处理点云帧所需时间，可估算总体能耗。考虑总功耗，ALFA 框架在仅软件配置时消耗约 3.361 W，在将 ALFA‑Unit 与 FESTA Extension 部署到硬件时消耗约 3.493 W。关于处理一帧 VLP‑16 点云所需能量，软件版平台约消耗 39.22 mJ，而硬件版则降低至 31.17 mJ。对于 HDL‑32，FESTA Extension 的软件版约需 63.19 mJ，硬件版约需 50.33 mJ。至于 HDL‑64，这些值分别升至 216.65 mJ 与 142.76 mJ。对于 VLS‑128，FESTA Extension 的软件版约需 328.20 mJ，而硬件版处理一帧点云的能量约为 246.57 mJ。

表 VIII

G. 讨论

使用 ALFA 框架评估 FESTA 算法的结果表明，在部署地面分割算法时具有显著优势，尤其是在利用 FPGA 技术进行硬件实现时。就性能而言，车辆周围环境会影响评估指标，因为低矮植被和小物体可能干扰地面点的分类。关于执行性能，随着点云尺寸增大，处理一帧点云所需时间也会增加，而通过部署硬件加速器可以部分缓解这一问题。然而，这会以资源为代价，因为对于更大、更高分辨率的点云，所需硬件资源会受到显著影响。

鉴于高分辨率传感器会产生大量数据，若采用 ROI（感兴趣区域），执行性能可以进一步提升。因为大部分重要数据位于车辆前方（即车辆运动方向），可以对点云进行裁剪区域，以减少帧大小。根据 Roriz 等人（⁴⁵）的方法，FESTA 算法以 120° 的 ROI（指向车辆前方）进行测试，其结果总结在表 IX 中。对于 VLP-16，裁剪框从点云中去除了约 17473（69.51%）个点，进一步将 FESTA 在硬件中的总处理时间从 8.92 ms 减少到 3.13 ms。对于 HDL-32，裁剪框去除了约 26023（62.27%）个点，对应的总处理时间为 6.29 ms。在相同场景下，HDL-64 和 VLS-128 的执行时间分别可从 40.87 ms 减少到 18.02 ms，以及从 70.59 ms 减少到 29.09 ms。

表 IX

第五章. 结论

本文介绍了 FESTA，一种基于 Anand 等人方法的地面分割算法，并在 ALFA 框架上部署，使用两种配置：基于软件的扩展和部署在 FPGA 上的嵌入式硬件加速扩展。算法的两种版本都实现了原工作相同的地面分割性能，同时显著提升了执行时间，这主要是通过利用硬件平台中现有的 FPGA 技术实现的。在使用高分辨率传感器（如 Velodyne VLS-128）时，也验证了硬件加速的必要性，实时要求仍然得到满足。

随后，下一步工作包括研究我们算法在分类步骤中使用的动态高程阈值，可根据周围环境进行选择。为提升执行性能，该方案可以改为使用基于硬件的存储块，而非使用 Xilinx Block Memory Generator IP。此方法将进一步提升点云中多点的并行处理，从而提升地面分割核心的性能。

脚注

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

参考文献

额外参考文献