前言
ORB-SLAM3 是一款基于特征点的实时视觉 SLAM（同步定位与地图构建）系统，由西班牙巴塞罗那自治大学团队开发，支持单目、双目、RGBD 相机及与 IMU（惯性测量单元）的融合，能在室内外多种环境中实现鲁棒的定位与三维地图构建，核心特点是支持多传感器融合、地图重用与多地图融合，且在精度和鲁棒性上达到行业领先水平。
实现该项目旨在掌握ZYNQ异构开发、图像处理、硬件加速适配的技能。项目实现还需要有C++、Verilog、Linux命令行等代码基础，高速信号开发等硬件基础,图像处理算法基础等等。
我决定选这个题目作为毕设了，这篇文章的作用就是把复杂的项目拆分成一个个较为小任务点。全部任务点完成了进行整合，就实现了一个完整的复杂的项目。
我也会一步步更新实现过程，在实现的同时，会同步更新学习的内容，该项目等我毕业了会把代码开源出来。
需求分析与任务拆分
阶段一：技术调研与资料收集
1.1 调研 ZYNQ 平台特性，选取合适的平台
硬件资源瓶颈量化对比，包括 CPU 算力上限、内存带宽与延迟FPGA、 逻辑资源上限、功耗与散热约束。
外设接口兼容性，摄像头、IMU驱动有没有现成的，方便移植吗？
1.2 初步解读ORB-SLAM3 源码结构，拆分可硬件化方案。
先知道每个模块负责的任务。
代码解读，涉及知识面甚广，可以放到后期PL端同步进行。
1.3 调研 SLAM 移植相关案例
寻找移植成功案例，不需要整个项目，深入到特征匹配，图像预处理等等都行，收集资料整理。输出文档。
1.4 制定技术路线
包括平台、实现架构方案，模块移植细节、外设选型、逻辑资源分配等等。
阶段二：ORB-SLAM代码分析与适配计划
2.1 核心模块梳理。输出文档
理清 ORB-SLAM3 关键功能模块及数据流向，聚焦 3 大核心线程：Tracking（特征提取 + 姿态估计）、Local Mapping（地图优化）、Loop Closing（回环检测），忽略次要辅助模块（如可视化）
画简易流程图：标注 “图像输入→特征提取→IMU 融合→地图更新” 的核心数据传递路径。（看时间，IMU融合可能不搞）
2.2 高耗时模块定位
为了降低开发学习和时间成本，只针对有必要硬件加速的模块进行处理，非必要不增加实体模块。
找出最该硬件加速的模块，这块需要凭经验（我没有，所以主要依赖获取别人的经验）
确定依赖库能否在 ZYNQ 上用，需做哪些简化。
已知核心依赖库有OpenCV、Eigen、Pangolin、DBoW2、go2、OpenCV、Eigen在petalinux已经囊括了，Pangolin是可视化的，移除。
go2、DBoW2等三方库可以参与交叉编译。
2.3 硬件加速和PL-PS端协同设计评估
确定”易实现、见效快” 的加速模块
PL-PS端协同分工。输出草图
2.4 制定量化标准和测试方案。输出测试文档
针对PL端的处理制定以 执行周期 为量化指标的测试。
针对PS端的处理以每秒处理帧数为量化指标，单独运行移植后的代码，进行Euroc参数集测试。（不一定跑得起来）
针对协同后的PS+PL端制定以 每秒处理帧数 的量化测试，和纯PS端对比，如果测试效果较好，可以和X86计算机处理速率进行对比。
针对生成地图质量进行评估（还没研究）
阶段三：PS端前期准备
3.1 开发平台
安装vivado 2020.2，petalinux 2020.2 版本要统一，否则硬件描述文件识别不了。HLS下载支持的版本就行。
安装完成平台后配置相关的系统环境，开发板是野火的，教程主要看正点原子的文档。野火文档版本不统一，踩坑了。
为petalinux配置交叉编译工具链。
代码管理（可选）
3.2 开发工具可用性验证
通过vivado 创建 二分频 模块验证功能。
用petalinux编译最小系统，烧录SD卡 上机验证。
用HLS 创建 一个例程 烧录验证。
3.3 用Petalinux定制可靠系统
这个步骤首次编译系统耗时较长，前期开发工具验证的时候可以利用空闲时间跑一遍。后续编译是增量编译。
装必要依赖库（OpenCV、Eigen）
装操作调试时候必要的库（Network支持库，ssh工具等等）
安装必要驱动（RTL8192CU网卡驱动，UVC摄像头设备）
编写设备树文件（使能网卡，petalinux会自动生成设备树，这边只要补充必要的就好了）
阶段四：PS端正式设计（源码移植）
4.1 ORB-SLAM3去可视化
删除pangolin 依赖源码。
解耦可视化模块（很多模块都有用到，先确保能通过编译）
删除cmake中对pangolin的编译语句
4.2 第三方依赖库编译改写
将主Cmake文件X86 编译指令改写为arm指令
删除第三方依赖库的X86 编译语句，继承主Cmake编译参数
有其他的报错再临场发挥吧
4.3上传编译好的PS端代码，跑纯PS端进行性能评估。
阶段五：PL端硬件加速设计
5.1 针对前期定下的核心加速进行HLS编写
使用HLS开发，需要理解数据类型的差异，然后根据官方给的源代码进行改写就行，比直接使用Verilog极大缩短开发周期。
1. FAST角点检测 HLS 编写
2. BRIEF 描述子生成运算 HLS代码编写
3. 词袋匹配的汉明距离运算 HLS代码编写
4. 其他核心模块编写，需要评估资源消耗！
5.2 边缘模块编写决策
1. IMU预积分（有上IMU再说）
2. DMA数据搬移 HLS编写（从0到1），用作PL+PS端通信，也可以考虑使用AXI 总线接口就好
3. 中断和同步模块，解决 PS 端与 PL 端的任务同步问题
4. 其他模块（还有摄像头驱动，各类外设通讯）
5.3 验证该阶段所有的模块功能，封装IP，添加到block 生成xsa硬件描述文件。
阶段六：PL+PS协同
6.1 替换核心运算模块，下放运算
1. 修改核心加速模块的源码，能调用PL端进行运算处理
2. 根据协同草图选择较为可靠的方案进行实现。
6.2 测试并验证总体功能，评估性能。
拓展功能
IMU惯传 的支持。
云通信，将运算结果输出至云端，利用云端实时解析生成可视化图。
CAN通信，将运算结果输出给其他核心，参与更大的系统中，实现加速单元侧载。
制作除核心板以外的底板PCBA。
后话
其实在2025年8月份左右，我已经做完阶段四了，后来忙别的事情去了就暂时没搞。
PL端在Github上有个 zynq-slam 的开源项目已经实现过了其中最难的FAST角点检测等等，他虽然是针对 ORB-SLAM2 编写。
我大概率是不会重复造轮子，会大量参考他的源码进行ORB-SLAM3的适配。
zynq-slam 这个项目中，PL-PS的方案是用AXI总线实现的，我如果想要通过Linux平台强大的兼容性去适配更多设备的话。可能会使用AXI-DMA，将数据统一分配到DDR3中。好处就是增加协同处理的效率，大部分设备的驱动用Linux平台去完成就好了。
目前在这个项目上耗时一个半月，后续持续跟进。
ORB-SLAM3硬件加速项目系列
点击文章下方标签获取整个系列更新文章！