适用于行星车的资源高效FPGA实现的SGM立体视差
摘要
由于通过中继卫星的间歇通信、信号传播延迟以及遥操作带宽有限，月球南极的探测车需要进行自主导航。 这种自主操作可分为四个相互关联的过程：感知、定位、制图和控制。 这四个过程必须在车载设备上完成，并且在计算和电力预算极为有限的条件下运行。 现代CMOS摄像头传感器在功耗和质量受限的情况下非常适合用于感知，但需要大量计算资源。 对于机器人探测车的自主性，感知过程必须实现对环境的三维感知。 使用一对摄像头的立体视觉是通过传统计算机视觉（CV）技术实现此目标的最小可行方案。 基于机器学习的方法尚未足够稳健、准确和/或可验证，无法在高影响力的太空任务中依赖。 因此，本文聚焦于使用经典CV中的Semi-Global Matching（SGM）视差算法的实现与部署，该算法兼具精度与计算性能。 由于太阳能驱动的探测车车载电力有限，SGM算法被实现于一个节能型系统芯片（SoC）上，该芯片包含四核RISC-V处理器和FPGA资源。 鉴于计算限制，SGM的全部功能都实现于FPGA晶体。 该算法必须使用System Verilog硬件描述语言（HDL）手动重新实现，而不使用任何高层综合（HLS）工具或其他开发者友好方案，因为它们要么生成低效代码，要么产生比我们目标平台可用资源显著更多的FPGA资源。 我们阐述了算法设计与实现，并将其结果与HLS生成的代码实现进行比较。
作者
Max Shevtsov 技术创新研究院，阿布扎比
Alexey Simonov 技术创新研究院，阿布扎比
Yusra Alkendi 技术创新研究院，阿布扎比
Anton Ivanov 阿布扎比技术创新研究院
出版信息
期刊: 2025 IEEE Aerospace Conference 年份: 2025 页码: 1-8 DOI: 10.1109/AERO63441.2025.11068515 文章编号: 11068515 ISSN: Electronic ISSN: 2996-2358, Print on Demand(PoD) ISSN: 1095-323X
指标
总下载量: 36
关键词
IEEE 关键词: Codes, Accuracy, Three-dimensional displays, Robot vision systems, Cameras, Fabrics, Sensors, System-on-chip, Hardware design languages, Field programmable gate arrays
索引词: Semi-global Matching, Implementation Of Algorithm, Space Exploration, Autonomous Navigation, Target Platform, High-level Synthesis, Pair Of Cameras, Error Rate, Power Constraint, Test Bench, Stereopsis, Parallel Algorithm, Stereo Images, Advanced Driver Assistance Systems, KITTI Dataset, Stereo Pairs, Disparity Values, Disparity Map, MATLAB Implementation, Stereo Image Pairs, Matching Cost
未定义
SECTION 1. 引言
多年来，基于视觉的感知算法已成为自动导航系统的关键组件 1，在诸如自动驾驶汽车、智能仓储机器人和自动化制造系统等广泛应用中发挥重要作用。这些算法使机器能够感知其环境，检测障碍物，并通过处理视觉数据 2 做出实时决策。对于需要实时导航和障碍物规避同等重要的太空任务，基于视觉的系统具有巨大的潜力 3。然而，在航天器机载计算机中实现这些算法，由于需要快速高效的计算，面临独特挑战。
在本研究中，我们详细阐述了在开展更广泛的行星车自动导航系统项目时遇到的一个问题的解决方案。
该项目从零开始设计并开发，要求集成定制的电子设备、软件和固件，以实现其目标。最复杂且最具挑战性的工作之一是开发能够在太空恶劣环境中实现实时基于视觉的导航的算法。
在考虑的各种算法中，立体视觉技术，例如半全局匹配（SGM）算法，因其能够生成视差图来帮助定位障碍物并估计其距离而脱颖而出。SGM在陆地应用中被广泛使用 4，并已成功在FPGA上实现高性能处理，使其成为我们航天器导航系统最合适的方法。然而，基于太空的应用提出了超出典型陆地使用案例的独特挑战。尺寸、电力和可靠性上的极端限制意味着对电子和固件设计的传统方法必须重新思考，以满足太空任务的既定要求。为太空飞行系统开发类似SGM的算法需要仔细考虑这些限制，确保硬件和软件都足够坚固，能够承受太空中的挑战，同时提供快速可靠的计算，这对自主导航至关重要。
本论文并非旨在提供 SGM 算法的全面概述或深入探讨其技术细节。相反，其目标是呈现在航天器导航计算机（NavC）开发过程中遇到的实际挑战，并描述克服该挑战所采用的方法。本文先介绍 SGM 算法（第 2 节），随后讨论项目挑战（第 3 节）。接下来，我们详细分析实施所用的方法论（第 4 节），并在第 5 节总结结果与测试。最后，第 6 节讨论未来计划，第 7 节给出结语。
图 1：立体对模型.
章节 2. 半全局匹配 (SGM)
SGM 是一种在已预先校正的立体图像对上运行的稠密视差图估计算法。该算法于 2005 年由 Heiko Hirschmüller 首次提出 5。由于其可预测的运行时间、在结果质量与计算时间之间的良好折中，以及其适用于在现场可编程门阵列（FPGA）或专用集成电路（ASIC）上进行快速并行实现，它在机器人和先进驾驶辅助系统等实时立体视觉应用中得到了广泛采用。与此同时，在 CPU 上运行此算法即使是对于较小分辨率也可能相当具有挑战性 6。这就是为什么在许多现代系统中 FPGAs 被用作最有效的芯片 7.
SGM 通过测量一幅立体图像中每个像素与另一幅图像子集内每个像素的相似度，实现实时视差图计算，如图 1 所示。给定一对已校正的立体图像，对具有坐标的像素，在另一幅图像中选择像素集合时，通常基于最大允许的视差位移来确定 8.
SGM 的核心思想是在多个方向上进行行优化，并通过求和从各方向到达视差像素的代价来计算聚合成本。方向数会影响算法的运行时间，通常 16 个方向能保证良好质量，而较少的方向也可用于加速执行。该算法的典型 8‑方向实现可通过两次遍历来计算成本：一次正向遍历，从左、左上、上、右上累加成本；一次反向遍历，从右、右下、下、左下累加成本，如图 2 所示。单遍历算法可仅使用五个方向实现 9.
立体重建是指在双摄像头并排安装的相机拍摄的立体图像对中寻找场景点投影的过程。相似度度量是匹配代价函数。像素越相似，代价函数越低。若独立于相邻像素为每个像素寻找相似性，则容易出错。照明变化、遮挡和噪声可能隐藏相似性或产生伪相似性。存在复杂的算法来缓解此问题。SGM 的一个关键进展是像素不是独立检查的，而是搜索匹配代价的全局最小值。为仍能快速得到结果，最小值并非在每个像素的整幅图像上搜索，而仅在穿过当前像素的直线路径上搜索，或称为“半全局” 10.
图 2：SGM：以 8 个方向传递
此外，引入了惩罚项以帮助获得平滑结果。若当前像素的视差与相邻像素的视差不同，该惩罚将被添加到代价中。这减少了离群值，因为惩罚降低了异常视差获得最小代价的可能性 11.
第 3 节：项目挑战
NavC 项目要求在严格的质量、尺寸和功耗限制下从零开始构建系统。组件选择因商业可用的空间电子设备的局限性而成为挑战，尤其是需要耐辐射的主要 FPGA/SoC 芯片。这限制了可选方案。许多 SGM 实现使用 Xilinx 或 Intel FPGA 芯片，它们为并行算法执行提供了足够的资源 12, 13, 14。虽然考虑了 Xilinx Zynq 平台，但采购问题导致寻找替代组件。
初步计划是将已有的已生成 HDL 集成到管道中，预先配置参数。选择 MATLAB 实现是因为其高效且便于使用 Vision HDL Toolbox 生成所需的算法代码 15。生成的 HDL 代码随后可以无缝地用于仿真软件或 FPGA，通过将模块与有效输入数据流对齐 16.
在审查生成的代码后，关于其面积和内存效率对我们的 FPGA 是否合适产生了疑问。尽管 MATLAB 工程师所针对的 Intel Arria 10 GX (115S2F45I1SG) FPGA 为他们的 SGM 实现（图 3）提供了足够的资源，但我们的平台限制了可选芯片的范围。此外，项目对 SGM 的要求是以每秒最高 5 帧、分辨率 640x360 的速率处理立体图像。尽管与 MATLAB 工程师的实现相比参数更低，他们的方案仍然显得对我们的平台过于苛刻。这表明需要一种更定制化的方案，能够兼顾性能与资源需求.
图 3：Intel FPGA Arria 10 GX 上 MATLAB SGM 资源使用情况
第 4 节：实现
本节详细说明了我们系统的实现，涵盖三个主要方面：目标平台、SGM 算法集成和 HDL 编码方法。每个方面都经过精细调整，以符合项目的性能和资源需求。
目标平台
根据所提供的研究，选择 Microchip 由于其在耐辐射和硬化芯片开发方面的长期专业经验，并且拥有可追溯至 Actel 时代的太空遗产 17。在 Microchip 的多种耐辐射 FPGA 家族中，例如 RTG、ProASIC 和 PolarFire 18，PolarFire SoC 家族被确定为最先进的选项图 4。PolarFire SoC 460（MPFS460），该家族中可用的最大 SoC，已被选为本项目的方案。
选择使用 SoC 而不是标准 FPGA 硬件的决定，是因为计划将图像处理流水线任务分配到 FPGA 硬件资源和 RISC‑V CPU 之间。此外，已将其中一颗 CPU 指定为运行 Robot Operating System (ROS2)。PolarFire 系列的一个关键优势是其片上非易失性存储器，这在航天应用中特别有用，因为它对单粒子翻转 (SEU) 具有免疫性 19.
为了测试首个项目版本和处理算法，选用了 Microchip Development Video Kit (MPFS250TS-IFCG 11521)，该工具包旨在支持多种图像处理方案的开发和测试，见图 5 20。该平台的关键特性包括：
SiFive U54 应用核心（4 个 RV64GC）以及安全启动
Sony 4K 双摄像头模块（IMX334 传感器）
板载 JTAG 或（多路复用）板载 FlashPro
4 GB DDR4 x 64
2 GB LPDDR4 x 32
8 GB eMMC 闪存和 SD 卡槽（多路复用）
4 x UART（通过 USB 桥接）
2 x GbE RJ-45 接口
1 x microUSB 高速 USB 2.0 OTG
HDMI2.0 视频输出
MIPI CSI-2 输入。
Sgm 实施
如前所述，第一个选项是使用 MATLAB 的 SGM 算法，并通过 MATLAB 的 HDL 工具箱生成 HDL 代码。然而，生成的代码超过了 Video Kit 上目标 FPGA 的资源和内存限制。在 MATLAB 的 HDL 工具箱中调整各种设置未能有效优化项目，因为瓶颈在于 MATLAB 算法内置的并行性。虽然这种并行性提高了速度，但由于板块资源有限，它也变成了一个劣势。理论上，该设计可以放在更大的 MPFS460 FPGA 上，但它会在峰值处理时导致功耗低效，因密集布局而产生多次时序违例，并且没有资源留给其他 IP 核。
另一种方法是使用通用的 HLS 编译器将 SGM 实现从高级语言转换为 HDL 代码。尽管 Microchip 提供了其 SmartHLS 解决方案，但由于缺乏可用的 C/C++ 实现和参考示例，我们并未选择此方案。HLS 工具在应用于更大规模的 FPGA/SoC 平台时尤为有利，因为它们能加速 HDL 代码生成。然而，尽管代码交付更快，生成代码的复杂性仍可能需要大量人工优化，以实现最佳性能和高效资源利用。在资源受限的环境中使用 HLS 时，这种开发速度与进一步改进需求之间的权衡是一个重要的考虑因素。因此，我们决定自行开发优化后的代码，以满足资源需求。MATLAB 提出的解决方案和算法管线被选为对比参考，如下文所示。
Hdl 编码
MATLAB 算法在资源使用方面的主要低效之处在于其对多个方向进行成本计算的并行实现，如图 6 所示。为了解决此问题，我们选择将这些计算按顺序执行，重复使用成本计算模块多次。算法管线如图 7 所示。虽然 MATLAB 的解决方案针对高分辨率、高帧率的视差计算进行了优化，但我们的需求涉及较低的分辨率和帧率，并且有严格的资源和功耗限制。我们在自定义实现中使用了 5 个方向和 64 个视差级别。尽管实现速度慢了几倍，但我们仍拥有足够的速度余量来满足项目需求。
与触发器相关的延迟被消除，与存储器位相关的延迟被优化。这种优化不仅在 DFF 和 LUT 资源上节省了显著量，且在我们的案例中，更重要的是在内部 FPGA 内存位上实现了显著节省。由于 SystemVerilog 方便处理多维数组并拥有有用的语法特性，以及众多面向对象选项，对测试平台开发有益，因而被选为目标语言。
SECTION 5. 结果与测试
自定义“手写”SGM实现与 MATLAB HDL 工具箱生成的版本之间的比较在表 1 中给出。评估在两个项目上进行，两个项目均将视频流水线与不同的 SGM 实现集成，目标是使用 Microchip Libero EDA 工具的 MPFS250 芯片。可以观察到，自定义实现使用的资源显著更少，约为 MATLAB 生成版本的六倍。即使在 SGM 模块上启用了三模冗余（TMR），自定义 SGM 的资源消耗仍低于普通 MATLAB SGM 实现。基于此分析，进一步开展了更实用的测试。
图 4：PlarFire SoC 结构图
图 5：PolarFire SoC 开发视频套件
初始测试集中在将 MATLAB 版本与自定义实现进行比较，使用 MATLAB 实现中提供的原始立体对图像。测试在 Mentor Graphics Modelsim Microsemi Pro 2022.2 Edition 仿真平台上进行。测试平台同时运行两个算法——MATLAB 生成的版本和自定义实现——为两者处理相同的逐像素数据流。比较了中间输出和最终输出，包括 Census 变换结果、汉明距离计算、聚合摘要输出以及视差图值。中间阶段的比较显示零误差。然而，在视差图的逐像素比较中，观察到 0.4% 的小错误率。尽管视差值存在这些差异，但它们几乎不易被人眼察觉，正如图 8、9 所示。造成这些差异最可能的原因是后处理块中舍入操作和插值模块的细微差异。结果以 256 阶灰度显示，以匹配原始 MATLAB 输出。
表 1：
下一阶段的测试涉及在 Video Kit 上运行立体图像，逐像素比较显示出 1.5% 的误差，见图 10。误差可能源于缺乏适当的时序约束，因为仅使用了自动生成的约束。这可能导致几个组合块的布线问题，从而在高频率下产生时序违例。预计这些问题将在最终设计中得到解决，当项目移植到目标 SoC 并正确组装所有模块和 IP 核心时。
图 6：MATLAB SGM 流水线
图 7：自定义 SGM 流水线
图 8：MATLAB SGM 视差图在 Modelsim 模拟中
图 9：自定义 SGM 视差图在 Modelsim 模拟中
图 10：自定义 SGM 在 Video Kit 上运行的视差图
为了避免仅对MATLAB示例立体图像进行测试限制，使用了知名的KITTI数据集 21、22 进行进一步评估。该数据集选取了若干已预处理、未失真且已校正的立体对。将这些图像裁剪为匹配FPGA设计分辨率，并加载到Video Kit的 DDR 内存中。运行期间，图像被按顺序读取并送入SGM模块，在那里计算视差值，并随后从相应的 DDR 地址检索。
已获取的视差图与真实数据进行了比较，真实数据在此案例中是作为 KITTI 数据集的一部分提供的 LIDAR 图像。 如图 12 所示，真实图像的上部为黑色，可能是因为 LIDAR 的视野受限，指向地面。 随数据集一起提供的脚本被用来执行比较，计算误差率。 没有真实或视差数据值的像素被排除在分析之外。 对于所有其他点，计算了真实值与对应视差图值之间的差异，但仅在其超过阈值 3 时才进行计算，阈值如原始数据集所述，见图 13。 结果使用 256 级灰度进行处理，以匹配原始 KITTI 数据集进行比较。
图 11：来自 KITTI 数据集的原始图像，左摄像头
图 12：自定义 SGM 视差图（上）与真实地图（下）的对比
所获得的误差率值相当合理，率与数据集示例中的相似，主要在 5–7% 范围内。若在 KITTI 数据集上进行测试，以下几种方法可帮助降低误差率，包括：
使用完整分辨率图像而非裁剪图像
测试整个数据集而非仅几个图像
在我们自定义的 HDL 设计中重构后处理模块
在比较之前对真实值和视差图值进行精确量化。
图 13：视差与真实值误差图
视频流水线的立体组件现已在 25 MHz 的全局时钟下高效运行，640x360 分辨率下实现 18 fps，同时仅占用目标芯片资源约 13%，即使包含 TMR 也如此。这种性能水平完全满足我们系统的需求。
第 6 节：未来计划
正如论文所讨论的，实施 SGM 算法已被证明是一项具有挑战性的任务，需要大量努力。展望未来，已确定以下关键任务作为未来重点，需要解决。
额外测试：提供额外测试，将我们的实现与不同的 HLS 生成算法进行比较。尽管位精确性并非我们的主要目标，但在大型知名数据集（如 KITTI）上测试不同实现有助于识别潜在差异。
优化时序约束：现有时序约束将被优化，以在更高速度下提升设计可持续性，确保设计满足所有角落情况的要求并最小化平均故障间隔时间（MTBF）。
尝试不同数量的方向： 将探索使用8或16方向计算的配置，并将结果与标准的5方向方法进行比较。如果改进显著，该方法可以由于可用的速度和资源余量无缝集成到立体视频处理管道中。
实施三重冗余： 在整体设计中为关键模块添加三重冗余，以提升可靠性并评估其对系统性能的影响。
其他太空项目： 目前有许多太空任务正在开发中，我们团队计划参与其中。我们需要探讨该算法在其中一些任务中的潜在应用，尤其是涉及自动驾驶用例和计算机视觉任务的，因为该算法实现可能成为它们的基石。
这些任务中的一些是不可避免的，并呈现了我们设计路线图的下一步，而其他任务则提供了改进和研究的机会，可能导致意外的积极结果。此时可以采取两条主要路径：针对速度或芯片面积进行设计优化。后者更适合我们的使用场景，因为行星车在低速行驶，且帧率需求允许从当前的 18 fps 显著降低。通过全面测试，我们的 SGM 实现已证明是一种可行的解决方案和成功的概念验证，使其适合在 NavC 项目中进一步开发。
第七节 结论
利用 FPGA 进行加速的车载操作，尤其是针对 SGM 的优势，已被广泛认可。使该实现独特的是所解决的约束集合和采用的方法，该方法利用最先进的 HDL 设计，而不依赖 HDL 生成工具。因此，得到的实现逻辑和内存使用都非常轻量，同时保持高效。值得注意的是，所提出的方案可能无法实现最高的帧率或工作频率，但它满足项目的具体需求，这对我们的案例更为重要。虽然低级代码开发耗时，但它能得到更紧凑、更高效的解决方案。