简介面向全国大学生智能汽车竞赛完全模型组参赛者的软件资源包配套Edgeboard-FZ3B硬件平台兼顾毕业设计与课程设计两类场景适合需要快速上手无人车视觉感知、模型部署与整车调试的学生和指导教师使用。包内共63个文件涵盖C与C源码、Python脚本、mobilenet-ssd模型与参数文件、串口通讯协议表格、说明文档、PDF手册以及演示用图片、动图和视频整体约34.13MB目录层次清晰按代码、资源与文档分区组织便于按需检索。目前已吸引307人学习能够覆盖从环境搭建、图像识别到下位机通讯的完整开发链路。借助该资源可获取完整赛题软件方案、上下位机通讯协议模板、模型权重、源码注释、调试截图与排错思路尤其适合从零搭建完全模型组软件框架、验证算法流程、备战竞赛和整理技术报告的团队参考。1. 拿到压缩包不是“解压即跑”Edgeboard-FZ3B 软件资源的真面目全国大学生智能汽车竞赛完全模型组里90% 的队伍会卡在同一个地方——不是模型训不出来而是好不容易把 ResNet 或者 PP-YOLO 训到 90% 的准确率烧到 Edgeboard-FZ3B 上以后要么起不来要么跑起来一帧要 300 毫秒。很多人第一反应是“板子太弱”但问题往往出在你对这份软件资源的理解上。这份 zip 不是一份“安装包”它是一整套面向 Zynq 平台的交叉编译链、预编译运行时库、模型转换工具链和示例工程的集合。装完只是开始真正的门槛在于搞清楚模型是怎么从 PC 上的 PaddlePaddle 格式变成板子上能跑的 int8 格式。写给准备打比赛或者刚拿到 FZ3B 的开发板、想快速上手的工程师这篇把链路拆开讲清楚。2. 拆开 zip 看架构Edgeboard-FZ3B 上软件栈、BSP 和模型部署链路2.1 zip 里一般躺着哪些东西完全模型组的软件资源包不同年份、不同渠道发的版本会有差异但大体上不会偏离下面这几类内容。拿到手先别急着跑 demo把目录结构摸清楚后面排错会快很多。目录/文件常见内容作用bsp/内核源码、设备树、U-Boot、交叉编译工具链板级支持包搞定底层 Linux 系统和硬件驱动libs/PaddleLite 预测库、OpenCV、依赖的 .so板端推理所需的运行时依赖models/官方示例模型检测、分类验证环境是否跑通的基准demo/图像采集、推理、串口发车的示例工程供二次开发的起点工程docs/烧录文档、编译文档、API 说明大部分人最先忽略但最该先看的东西这里有一个经常被误解的点Edgeboard-FZ3B 的本质是 Xilinx Zynq 架构即 ARM 处理器 FPGA 可编程逻辑在同一个芯片上。跑深度学习模型时ARM 负责 Linux 系统、图像读取、预处理和控制逻辑FPGA 里烧录的 DPUDeep Processing UnitIP 核负责卷积、池化这类重计算。所以这份 zip 里的库文件并不是普通的 x86 版动态库而是为 ARM 交叉编译、并且针对 DPU 做了算子映射的特殊版本。用错库或者直接把 PC 上的 so 文件拷过去是新手最容易踩的坑。常见做法是拿到 zip 后先按照 docs 里的说明完成系统烧录然后跑一个官方自带的分类模型确认整条链路是通的。之后再开始动你自己的模型。不要跳过这一步因为后续所有问题排查都依赖一个“已知可用的环境基线”。2.2 从 PaddlePaddle 到 DPU模型格式转换链在 PC 上用 PaddlePaddle 训练出来的模型产出的是.pdmodel和.pdiparams文件。但 Edgeboard-FZ3B 的 DPU 并不能直接执行这种格式它认识的是经过 PaddleLite 优化后的.nbnaive buffer格式。中间转换的路径是PaddlePaddle 训练产出 FP32 模型 ↓ PaddleSlim / 离线量化 INT8 量化模型.pdmodel .pdiparams ↓ paddle_lite_opt 工具 .paddlelite 格式 / .nb 格式 ↓ 部署到 FZ3B 的 ARM 侧 PaddleLite Runtime 加载并调用 DPU 执行为什么要转成 int8因为板子上的 DSP 和 DPU 针对定点运算做了大量优化int8 计算比 FP32 快数倍而且内存带宽占用大幅降低。比赛场景里摄像头采集到的画面经过 resize 后直接喂给 DPU延迟预算通常只有几十毫秒。FP32 模型在 ARM 上跑根本达不到这个要求。常见做法是在 PC 上先用 PaddleSlim 做离线量化确定模型在 int8 下精度损失可以接受再转成 nb。转换命令大致长这样paddle_lite_opt \ --model_filemodel.pdmodel \ --param_filemodel.pdiparams \ --optimize_outmodel_int8 \ --optimize_out_typenaive_buffer \ --valid_targetsarm参数说明--model_file和--param_file分别是训练产出的模型结构文件与权重文件--optimize_out指定输出文件前缀--optimize_out_type用naive_buffer是因为它加载速度比普通 protobuf 更快适合板端启动时使用--valid_targets指定目标平台这里写arm是因为 PaddleLite 在 FZ3B 上是通过 ARM 侧调用底层算子的有的固件版本会要求填dpu或者opencl具体以随包的文档说明为准。转换后生成.nb文件这个文件直接拷到板子上就能被 PaddleLite Runtime 加载。2.3 为什么软硬件协同比单纯堆模型重要完全模型组的比赛规则允许使用官方指定的 Edgeboard 平台大家的算力上限是一样的。这时候比的就不是谁的模型大、谁的参数量多而是谁能在同样的算力约束下把“采集-预处理-推理-控制”这条链路的每一环都优化到位。很多队伍花大量时间在模型蒸馏和剪枝上却忽略了数据从摄像头到 DPU 之间的搬运开销。一个典型的例子OpenCV 的imread加resize加normalize在一颗嵌入式 ARM 上可能要消耗 20 到 30 毫秒。这个数字在 PC 上几乎可以忽略但在板端就是灾难。所以 zip 里的 demo 工程通常会对图像预处理做特殊优化比如使用 NEON 指令加速、把归一化融合进卷积层、或者直接操作 DMA 缓冲区避免内存拷贝。这些技巧的源码都在 demo 里建议逐行读懂再动手改。3. 环境搭建与本地跑通在 Edgeboard-FZ3B 上完成第一次推理3.1 最小环境准备清单在碰代码之前先把环境准备到位。以下是我自己在比赛中踩过坑之后整理的最少步骤每一步都是一条命令或一个检查点。# 1. 在 PC 上安装交叉编译工具链以 aarch64-linux-gnu 为例 sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 2. 解压官方软件资源包并确认目录结构 unzip 全国大学生智能汽车竞赛-完全模型组-软件资源Edgeboard-FZ3B.zip -d fz3b_sdk cd fz3b_sdk ls -la # 3. 检查预测库是否存在而且架构正确 file libs/PaddleLite/lib/libpaddle_light_api_shared.so # 期望输出中包含 ARM aarch64 或类似字样file命令的输出是关键。如果你看到x86-64说明拿错了库版本看到aarch64说明交叉编译环境初步正常。很多队伍的 demo 编译失败最后发现是编译器版本对不上或者库文件路径引用错误这类问题在准备阶段解决成本最低。3.2 交叉编译 demo第一个可执行文件的诞生官方 zip 里的 demo 工程通常是 CMake 组织的。交叉编译的核心是给 CMake 传一个工具链文件告诉它“我们用 ARM 编译器链 ARM 的库生成 ARM 的可执行文件”。# toolchain.aarch64.cmake SET(CMAKE_SYSTEM_NAME Linux) SET(CMAKE_SYSTEM_PROCESSOR aarch64) SET(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) SET(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) SET(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu) SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)这个工具链文件解决的是“在哪找头文件、在哪找库、用哪个编译器”三件事。CMAKE_FIND_ROOT_PATH指向 ARM 版的库所在目录MODE_LIBRARY ONLY表示只从该目录搜索库避免链到 PC 上的 x86 版本。接下来构建mkdir build cd build cmake .. -DCMAKE_TOOLCHAIN_FILE../toolchain.aarch64.cmake \ -DPADDLELITE_DIR../libs/PaddleLite make -j$(nproc) # nproc 在 mac 上可能不存在改成固定值 4 即可编译完成后把生成的可执行文件、.nb模型和依赖的.so一起拷贝到板子。可以用 scp也可以用 SD 卡比赛现场一般用 U 盘隔离传递防止网络环境不稳定。3.3 编写第一个推理代码图片分类作为链路验证环境通了之后先不急着跑比赛模型。用一张简单的图片分类 demo 验证 PaddleLite Runtime 和 DPU 的配合是否正常。下面是一段最小可用的 C 推理代码也是官方常见做法的浓缩。#include iostream #include vector #include paddlelite_api.h // PaddleLite 头文件 int main() { // 1. 配置加载器 paddle::lite_api::MobileConfig config; config.set_model_from_file(/home/root/models/model_int8.nb); config.set_power_mode(paddle::lite_api::PowerMode::LITE_POWER_HIGH); config.set_threads(2); // 2. 创建预测器 auto predictor paddle::lite_api::CreatePaddlePredictor paddle::lite_api::MobileConfig(config); // 3. 构造输入 auto input_tensor predictor-GetInput(0); input_tensor-Resize({1, 3, 224, 224}); auto* input_data input_tensor-mutable_datafloat(); // 这里应该填入预处理后的图像数据假数据仅用于链路验证 for (int i 0; i 3 * 224 * 224; i) input_data[i] 0.0f; // 4. 执行推理 predictor-Run(); // 5. 读取输出 auto output_tensor predictor-GetOutput(0); auto* output_data output_tensor-datafloat(); std::cout output num: output_tensor-shape().size() std::endl; return 0; }逻辑说明第一步通过MobileConfig指定模型路径、功耗模式和线程数。set_power_mode直接影响 CPU 频率调度策略比赛场景一般用LITE_POWER_HIGH保证推理速度但如果发现板子过热降频要改成LITE_POWER_BALANCED甚至LITE_POWER_LOW。第二步创建预测器内部完成模型加载和算子选择。第三步把预处理后的图像数据填充进输入张量Resize时要注意模型的输入尺寸必须与训练时保持一致这个例子假设是224x224完全模型组的目标检测模型通常是320x320或352x352。第四、五步执行并取回输出。如果这一步能稳定跑通整条软件链路就通了。3.4 从分类到检测给 Edgeboard-FZ3B 换上自己的检测模型分类模型验证通过后就可以尝试部署目标检测模型了。完全模型组要识别的元素包括斑马线、锥桶、圆环和十字路口等本质上是一个多目标检测任务。部署时和分类模型的主要差异在输出解析部分——检测模型的输出是候选框坐标、置信度和类别 ID。代码结构上将检测模型的输出数据解析出来需要知道输出张量的排布。以常见的 YOLO 系列为例输出通常是一个[N, anchors, 5classes]的张量后面接 NMS非极大值抑制过滤重叠框。这部分逻辑在 PC 上可以用 Python 轻松写但板端工程一般用 C 实现逐层遍历张量数据做阈值过滤。// 输出解析的核心伪逻辑 for (int i 0; i num_boxes; i) { float score output_data[i * 7 4]; // 不同模型排布不同以实际为准 if (score 0.5) { // 置信度阈值 int cls static_castint(output_data[i * 7 5]); float x1 output_data[i * 7 0]; float y1 output_data[i * 7 1]; float x2 output_data[i * 7 2]; float y2 output_data[i * 7 3]; // 交给控制逻辑去用 } }这里要特别提醒输出张量在 int8 量化后有些版本会输出反量化后的 float 值有些则要求手动反量化。检查方法是在代码里把原始输出值打印出来跟 PC 上 Python 推理的输出对比一下量级。差一个缩放因子是正常现象不要怀疑板子有问题。4. 精度掉点与算子报错Edgeboard-FZ3B 部署中最常见的五类故障4.1 现象一模型转换失败提示算子不支持这是最劝退的一类问题。PC 上的 Paddle 模型里有些算子 DPU 硬件不支持。解决办法有三种按优先级排列第一换模型结构把不支持的算子从网络里删掉或替换第二把不支持的算子标记为“在 ARM 上执行”而不是强制放到 DPU这会损失一部分速度第三升级固件版本新版本往往补齐更多算子。提示在转换之前先查一下 PaddleLite 官方算子支持列表比报错了再去改要省时间。比赛类项目建议直接从官方支持的模型库中选主干网络少自己造结构。实际排查中用日志确认是最直接的# 在板子上运行时启用详细日志 export GLOG_v1 ./your_demo 21 | grep -iE error|fail|unsupported|op_如果日志中出现类似unsupported op的提示说明某个算子在当前 DPU 版本上没有实现。把这个算子名字记下来回到网络结构里找到它在上游替换掉或者用 PaddleX 里的“模型裁剪”能力先去掉无关分支。4.2 现象二int8 量化后精度骤降掉两三个点int8 量化不是简单的“训练后转一下”。量化过程需要用一批有代表性的图片做校准统计每一层激活值的分布然后据此确定缩放因子。很多队伍直接用 50 张比赛现场图做校准集结果晴天变阴天、赛道光照一变模型就懵了。正确做法是准备 200 到 500 张覆盖不同光照、不同赛道元素的图片尽可能模拟比赛当天的环境。量化时按常见做法使用 KL 散度校准算法# PaddleSlim 离线量化示例 from paddle.static.quantization import PostTrainingQuantization quant PostTrainingQuantization( executorexe, model_dir./fp32_model, sample_generatordata_loader, # 返回 N 张校准图 batch_size8, algohist, # KL 散度校准 round_type1) # 四舍五入实测比截断效果好 quant.save_quantized_model(./int8_model)algohist表示使用直方图统计激活分布再按 KL 散度寻找最优量化阈值round_type1是四舍五入0是截断。经验上看分类模型用两者差别不大检测模型用四舍五入更稳。保存出来的模型需要再走一遍上一章说的paddle_lite_opt转换才能在板子上加载。如果量化后精度还是不行就在模型结构里给检测头加一层BN并冻结或者改用混合量化只量化主干检测头保持 FP32。4.3 现象三推理速度忽快忽慢比赛后半程明显变卡FZ3B 在长时间高负载运行时FPGA 和 ARM 的温度会上升。温度达到阈值后系统会主动降频保护。表现就是前几分钟推理延迟稳定在 30ms跑了十分钟后变成 60ms。排查时看温度cat /sys/class/thermal/thermal_zone0/temp # 输出除以 1000 就是摄氏度如果温度超过 75 度就要考虑散热方案。比赛现场常见做法是在板子背面贴散热片、加一个小风扇或者把板子支架设计成有利于空气流通的形状。软件层面检查set_power_mode是否设成了LITE_POWER_HIGH如果过温频繁改成BALANCED牺牲一点性能换取稳定。4.4 现象四内存不足程序跑一会就被 kill板子的 RAM 有限模型的中间计算结果如果太大很容易 OOM。DDR 带宽也是瓶颈——输入分辨率 640x640 的模型中间特征图占用非常大。比赛场景下输入分辨率追求 320x320 而不是 640x640精度差距可以通过数据增强和更优的主干网络弥补。另外一个隐蔽的内存泄漏点是 OpenCV 的Mat没有释放或者图像数据不断拷贝每帧多几 MB几分钟就爆了。检查方法free -m # 看总内存和可用内存 top -d 1 # 实时看进程内存占用 dmesg | tail -20 # 看是否出现 out of memory 相关的内核日志定位到是模型还是代码导致的内存增长然后针对性处理。4.5 现象五输入图像颜色错乱检测结果明显不对如果板端推理结果和 PC 端对不上先查三点图像的通道顺序BGR 还是 RGB、像素值范围0-255 还是 0-1、归一化参数是否一致。PaddlePaddle 训练时如果用的是 ImageNet 的mean[0.485,0.456,0.406], std[0.229,0.224,0.225]板端推理也要用一模一样的值。OpenCV 默认读进来是 BGR如果你的模型是按 RGB 训练的中间必须做cv::cvtColor转换。在板子上打印几个像素值和训练预处理后的结果对比一下这是最快的定位方式。5. 把算力花在刀刃上Edgeboard-FZ3B 上三个值得抠的细节5.1 比较检测框和实际位置之间的偏差做好延时补偿推理占用几十毫秒车在这段时间里已经往前跑了不短的距离。如果控制逻辑用的是上一帧的图像检测结果方向控制会有明显的滞后。常见做法是给检测结果加一个时间戳控制模块根据当前车速估算车的实际位置对检测框做位置补偿。具体到代码层面就是记录每一帧推理完成时车的速度然后根据这个速度修正目标点的横向偏差。// 延时补偿的核心逻辑 float speed_ms current_speed / 3.6; // km/h - m/s float latency infer_end_time - image_capture_time; // 单位秒 float distance_offset speed_ms * latency; // 车子在推理期间的行驶距离 // 用 distance_offset 修正检测框与车头的相对位置这个补偿不改变模型但能明显改善高速入弯时的控制平滑度。控制周期建议固定在 10ms 到 20ms并且要与推理线程解耦不要“推理阻塞就停发控制指令”否则会出现一段失去控制的时间窗口。5.2 用线程绑定把推理、采集、控制安排在不同 CPU 核心上FZ3B 的 ARM 侧有多个核心默认调度器不会帮你按“实时性优先级”分配核心。推理线程、摄像头采集线程、串口发送线程互相抢占 CPU会导致偶发的长延迟尖峰。#include sched.h #include unistd.h void bind_thread_to_core(int core_id) { cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(core_id, cpuset); sched_setaffinity(0, sizeof(cpuset), cpuset); }在线程入口调用bind_thread_to_core(0)、bind_thread_to_core(1)等把实时性要求最高的感知线程放到独立核心上其他业务放另外的核心。对于完全模型组来说推理是主循环占一个核图像采集和预处理占另一个控制输出和日志在一个低优先级线程。三个线程间用无锁队列或者带超时的双缓冲传递数据避免一把大锁锁住所有流程。5.3 把预处理里的“隐形成本”可视化很多人以为推理延迟就是模型本身的耗时实际上整条链路里imread、resize、normalize、数据拷贝每一项都可能比模型本身还贵。建议把每一段耗时打点打出来auto t0 std::chrono::steady_clock::now(); // 图像采集 auto t1 std::chrono::steady_clock::now(); // 预处理 auto t2 std::chrono::steady_clock::now(); // 推理 auto t3 std::chrono::steady_clock::now(); // 后处理 auto t4 std::chrono::steady_clock::now();连续记录 100 帧把各段耗时的中位数和 P99 报出来。如果发现 resize 或 normalize 占比过高常见做法是把 resize 和归一化合并在一个循环里、用 NEON 指令并行处理多个像素、或者直接把归一化参数合进模型的第一个卷积层省掉一次全图遍历。这些优化在 PC 上收益可忽略在板上却是实打实的每帧 5 到 10 毫秒。本文还有配套的精品资源点击获取
Edgeboard-FZ3B模型部署全解析：从PaddlePaddle到DPU的实战指南
简介面向全国大学生智能汽车竞赛完全模型组参赛者的软件资源包配套Edgeboard-FZ3B硬件平台兼顾毕业设计与课程设计两类场景适合需要快速上手无人车视觉感知、模型部署与整车调试的学生和指导教师使用。包内共63个文件涵盖C与C源码、Python脚本、mobilenet-ssd模型与参数文件、串口通讯协议表格、说明文档、PDF手册以及演示用图片、动图和视频整体约34.13MB目录层次清晰按代码、资源与文档分区组织便于按需检索。目前已吸引307人学习能够覆盖从环境搭建、图像识别到下位机通讯的完整开发链路。借助该资源可获取完整赛题软件方案、上下位机通讯协议模板、模型权重、源码注释、调试截图与排错思路尤其适合从零搭建完全模型组软件框架、验证算法流程、备战竞赛和整理技术报告的团队参考。1. 拿到压缩包不是“解压即跑”Edgeboard-FZ3B 软件资源的真面目全国大学生智能汽车竞赛完全模型组里90% 的队伍会卡在同一个地方——不是模型训不出来而是好不容易把 ResNet 或者 PP-YOLO 训到 90% 的准确率烧到 Edgeboard-FZ3B 上以后要么起不来要么跑起来一帧要 300 毫秒。很多人第一反应是“板子太弱”但问题往往出在你对这份软件资源的理解上。这份 zip 不是一份“安装包”它是一整套面向 Zynq 平台的交叉编译链、预编译运行时库、模型转换工具链和示例工程的集合。装完只是开始真正的门槛在于搞清楚模型是怎么从 PC 上的 PaddlePaddle 格式变成板子上能跑的 int8 格式。写给准备打比赛或者刚拿到 FZ3B 的开发板、想快速上手的工程师这篇把链路拆开讲清楚。2. 拆开 zip 看架构Edgeboard-FZ3B 上软件栈、BSP 和模型部署链路2.1 zip 里一般躺着哪些东西完全模型组的软件资源包不同年份、不同渠道发的版本会有差异但大体上不会偏离下面这几类内容。拿到手先别急着跑 demo把目录结构摸清楚后面排错会快很多。目录/文件常见内容作用bsp/内核源码、设备树、U-Boot、交叉编译工具链板级支持包搞定底层 Linux 系统和硬件驱动libs/PaddleLite 预测库、OpenCV、依赖的 .so板端推理所需的运行时依赖models/官方示例模型检测、分类验证环境是否跑通的基准demo/图像采集、推理、串口发车的示例工程供二次开发的起点工程docs/烧录文档、编译文档、API 说明大部分人最先忽略但最该先看的东西这里有一个经常被误解的点Edgeboard-FZ3B 的本质是 Xilinx Zynq 架构即 ARM 处理器 FPGA 可编程逻辑在同一个芯片上。跑深度学习模型时ARM 负责 Linux 系统、图像读取、预处理和控制逻辑FPGA 里烧录的 DPUDeep Processing UnitIP 核负责卷积、池化这类重计算。所以这份 zip 里的库文件并不是普通的 x86 版动态库而是为 ARM 交叉编译、并且针对 DPU 做了算子映射的特殊版本。用错库或者直接把 PC 上的 so 文件拷过去是新手最容易踩的坑。常见做法是拿到 zip 后先按照 docs 里的说明完成系统烧录然后跑一个官方自带的分类模型确认整条链路是通的。之后再开始动你自己的模型。不要跳过这一步因为后续所有问题排查都依赖一个“已知可用的环境基线”。2.2 从 PaddlePaddle 到 DPU模型格式转换链在 PC 上用 PaddlePaddle 训练出来的模型产出的是.pdmodel和.pdiparams文件。但 Edgeboard-FZ3B 的 DPU 并不能直接执行这种格式它认识的是经过 PaddleLite 优化后的.nbnaive buffer格式。中间转换的路径是PaddlePaddle 训练产出 FP32 模型 ↓ PaddleSlim / 离线量化 INT8 量化模型.pdmodel .pdiparams ↓ paddle_lite_opt 工具 .paddlelite 格式 / .nb 格式 ↓ 部署到 FZ3B 的 ARM 侧 PaddleLite Runtime 加载并调用 DPU 执行为什么要转成 int8因为板子上的 DSP 和 DPU 针对定点运算做了大量优化int8 计算比 FP32 快数倍而且内存带宽占用大幅降低。比赛场景里摄像头采集到的画面经过 resize 后直接喂给 DPU延迟预算通常只有几十毫秒。FP32 模型在 ARM 上跑根本达不到这个要求。常见做法是在 PC 上先用 PaddleSlim 做离线量化确定模型在 int8 下精度损失可以接受再转成 nb。转换命令大致长这样paddle_lite_opt \ --model_filemodel.pdmodel \ --param_filemodel.pdiparams \ --optimize_outmodel_int8 \ --optimize_out_typenaive_buffer \ --valid_targetsarm参数说明--model_file和--param_file分别是训练产出的模型结构文件与权重文件--optimize_out指定输出文件前缀--optimize_out_type用naive_buffer是因为它加载速度比普通 protobuf 更快适合板端启动时使用--valid_targets指定目标平台这里写arm是因为 PaddleLite 在 FZ3B 上是通过 ARM 侧调用底层算子的有的固件版本会要求填dpu或者opencl具体以随包的文档说明为准。转换后生成.nb文件这个文件直接拷到板子上就能被 PaddleLite Runtime 加载。2.3 为什么软硬件协同比单纯堆模型重要完全模型组的比赛规则允许使用官方指定的 Edgeboard 平台大家的算力上限是一样的。这时候比的就不是谁的模型大、谁的参数量多而是谁能在同样的算力约束下把“采集-预处理-推理-控制”这条链路的每一环都优化到位。很多队伍花大量时间在模型蒸馏和剪枝上却忽略了数据从摄像头到 DPU 之间的搬运开销。一个典型的例子OpenCV 的imread加resize加normalize在一颗嵌入式 ARM 上可能要消耗 20 到 30 毫秒。这个数字在 PC 上几乎可以忽略但在板端就是灾难。所以 zip 里的 demo 工程通常会对图像预处理做特殊优化比如使用 NEON 指令加速、把归一化融合进卷积层、或者直接操作 DMA 缓冲区避免内存拷贝。这些技巧的源码都在 demo 里建议逐行读懂再动手改。3. 环境搭建与本地跑通在 Edgeboard-FZ3B 上完成第一次推理3.1 最小环境准备清单在碰代码之前先把环境准备到位。以下是我自己在比赛中踩过坑之后整理的最少步骤每一步都是一条命令或一个检查点。# 1. 在 PC 上安装交叉编译工具链以 aarch64-linux-gnu 为例 sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 2. 解压官方软件资源包并确认目录结构 unzip 全国大学生智能汽车竞赛-完全模型组-软件资源Edgeboard-FZ3B.zip -d fz3b_sdk cd fz3b_sdk ls -la # 3. 检查预测库是否存在而且架构正确 file libs/PaddleLite/lib/libpaddle_light_api_shared.so # 期望输出中包含 ARM aarch64 或类似字样file命令的输出是关键。如果你看到x86-64说明拿错了库版本看到aarch64说明交叉编译环境初步正常。很多队伍的 demo 编译失败最后发现是编译器版本对不上或者库文件路径引用错误这类问题在准备阶段解决成本最低。3.2 交叉编译 demo第一个可执行文件的诞生官方 zip 里的 demo 工程通常是 CMake 组织的。交叉编译的核心是给 CMake 传一个工具链文件告诉它“我们用 ARM 编译器链 ARM 的库生成 ARM 的可执行文件”。# toolchain.aarch64.cmake SET(CMAKE_SYSTEM_NAME Linux) SET(CMAKE_SYSTEM_PROCESSOR aarch64) SET(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) SET(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) SET(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu) SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)这个工具链文件解决的是“在哪找头文件、在哪找库、用哪个编译器”三件事。CMAKE_FIND_ROOT_PATH指向 ARM 版的库所在目录MODE_LIBRARY ONLY表示只从该目录搜索库避免链到 PC 上的 x86 版本。接下来构建mkdir build cd build cmake .. -DCMAKE_TOOLCHAIN_FILE../toolchain.aarch64.cmake \ -DPADDLELITE_DIR../libs/PaddleLite make -j$(nproc) # nproc 在 mac 上可能不存在改成固定值 4 即可编译完成后把生成的可执行文件、.nb模型和依赖的.so一起拷贝到板子。可以用 scp也可以用 SD 卡比赛现场一般用 U 盘隔离传递防止网络环境不稳定。3.3 编写第一个推理代码图片分类作为链路验证环境通了之后先不急着跑比赛模型。用一张简单的图片分类 demo 验证 PaddleLite Runtime 和 DPU 的配合是否正常。下面是一段最小可用的 C 推理代码也是官方常见做法的浓缩。#include iostream #include vector #include paddlelite_api.h // PaddleLite 头文件 int main() { // 1. 配置加载器 paddle::lite_api::MobileConfig config; config.set_model_from_file(/home/root/models/model_int8.nb); config.set_power_mode(paddle::lite_api::PowerMode::LITE_POWER_HIGH); config.set_threads(2); // 2. 创建预测器 auto predictor paddle::lite_api::CreatePaddlePredictor paddle::lite_api::MobileConfig(config); // 3. 构造输入 auto input_tensor predictor-GetInput(0); input_tensor-Resize({1, 3, 224, 224}); auto* input_data input_tensor-mutable_datafloat(); // 这里应该填入预处理后的图像数据假数据仅用于链路验证 for (int i 0; i 3 * 224 * 224; i) input_data[i] 0.0f; // 4. 执行推理 predictor-Run(); // 5. 读取输出 auto output_tensor predictor-GetOutput(0); auto* output_data output_tensor-datafloat(); std::cout output num: output_tensor-shape().size() std::endl; return 0; }逻辑说明第一步通过MobileConfig指定模型路径、功耗模式和线程数。set_power_mode直接影响 CPU 频率调度策略比赛场景一般用LITE_POWER_HIGH保证推理速度但如果发现板子过热降频要改成LITE_POWER_BALANCED甚至LITE_POWER_LOW。第二步创建预测器内部完成模型加载和算子选择。第三步把预处理后的图像数据填充进输入张量Resize时要注意模型的输入尺寸必须与训练时保持一致这个例子假设是224x224完全模型组的目标检测模型通常是320x320或352x352。第四、五步执行并取回输出。如果这一步能稳定跑通整条软件链路就通了。3.4 从分类到检测给 Edgeboard-FZ3B 换上自己的检测模型分类模型验证通过后就可以尝试部署目标检测模型了。完全模型组要识别的元素包括斑马线、锥桶、圆环和十字路口等本质上是一个多目标检测任务。部署时和分类模型的主要差异在输出解析部分——检测模型的输出是候选框坐标、置信度和类别 ID。代码结构上将检测模型的输出数据解析出来需要知道输出张量的排布。以常见的 YOLO 系列为例输出通常是一个[N, anchors, 5classes]的张量后面接 NMS非极大值抑制过滤重叠框。这部分逻辑在 PC 上可以用 Python 轻松写但板端工程一般用 C 实现逐层遍历张量数据做阈值过滤。// 输出解析的核心伪逻辑 for (int i 0; i num_boxes; i) { float score output_data[i * 7 4]; // 不同模型排布不同以实际为准 if (score 0.5) { // 置信度阈值 int cls static_castint(output_data[i * 7 5]); float x1 output_data[i * 7 0]; float y1 output_data[i * 7 1]; float x2 output_data[i * 7 2]; float y2 output_data[i * 7 3]; // 交给控制逻辑去用 } }这里要特别提醒输出张量在 int8 量化后有些版本会输出反量化后的 float 值有些则要求手动反量化。检查方法是在代码里把原始输出值打印出来跟 PC 上 Python 推理的输出对比一下量级。差一个缩放因子是正常现象不要怀疑板子有问题。4. 精度掉点与算子报错Edgeboard-FZ3B 部署中最常见的五类故障4.1 现象一模型转换失败提示算子不支持这是最劝退的一类问题。PC 上的 Paddle 模型里有些算子 DPU 硬件不支持。解决办法有三种按优先级排列第一换模型结构把不支持的算子从网络里删掉或替换第二把不支持的算子标记为“在 ARM 上执行”而不是强制放到 DPU这会损失一部分速度第三升级固件版本新版本往往补齐更多算子。提示在转换之前先查一下 PaddleLite 官方算子支持列表比报错了再去改要省时间。比赛类项目建议直接从官方支持的模型库中选主干网络少自己造结构。实际排查中用日志确认是最直接的# 在板子上运行时启用详细日志 export GLOG_v1 ./your_demo 21 | grep -iE error|fail|unsupported|op_如果日志中出现类似unsupported op的提示说明某个算子在当前 DPU 版本上没有实现。把这个算子名字记下来回到网络结构里找到它在上游替换掉或者用 PaddleX 里的“模型裁剪”能力先去掉无关分支。4.2 现象二int8 量化后精度骤降掉两三个点int8 量化不是简单的“训练后转一下”。量化过程需要用一批有代表性的图片做校准统计每一层激活值的分布然后据此确定缩放因子。很多队伍直接用 50 张比赛现场图做校准集结果晴天变阴天、赛道光照一变模型就懵了。正确做法是准备 200 到 500 张覆盖不同光照、不同赛道元素的图片尽可能模拟比赛当天的环境。量化时按常见做法使用 KL 散度校准算法# PaddleSlim 离线量化示例 from paddle.static.quantization import PostTrainingQuantization quant PostTrainingQuantization( executorexe, model_dir./fp32_model, sample_generatordata_loader, # 返回 N 张校准图 batch_size8, algohist, # KL 散度校准 round_type1) # 四舍五入实测比截断效果好 quant.save_quantized_model(./int8_model)algohist表示使用直方图统计激活分布再按 KL 散度寻找最优量化阈值round_type1是四舍五入0是截断。经验上看分类模型用两者差别不大检测模型用四舍五入更稳。保存出来的模型需要再走一遍上一章说的paddle_lite_opt转换才能在板子上加载。如果量化后精度还是不行就在模型结构里给检测头加一层BN并冻结或者改用混合量化只量化主干检测头保持 FP32。4.3 现象三推理速度忽快忽慢比赛后半程明显变卡FZ3B 在长时间高负载运行时FPGA 和 ARM 的温度会上升。温度达到阈值后系统会主动降频保护。表现就是前几分钟推理延迟稳定在 30ms跑了十分钟后变成 60ms。排查时看温度cat /sys/class/thermal/thermal_zone0/temp # 输出除以 1000 就是摄氏度如果温度超过 75 度就要考虑散热方案。比赛现场常见做法是在板子背面贴散热片、加一个小风扇或者把板子支架设计成有利于空气流通的形状。软件层面检查set_power_mode是否设成了LITE_POWER_HIGH如果过温频繁改成BALANCED牺牲一点性能换取稳定。4.4 现象四内存不足程序跑一会就被 kill板子的 RAM 有限模型的中间计算结果如果太大很容易 OOM。DDR 带宽也是瓶颈——输入分辨率 640x640 的模型中间特征图占用非常大。比赛场景下输入分辨率追求 320x320 而不是 640x640精度差距可以通过数据增强和更优的主干网络弥补。另外一个隐蔽的内存泄漏点是 OpenCV 的Mat没有释放或者图像数据不断拷贝每帧多几 MB几分钟就爆了。检查方法free -m # 看总内存和可用内存 top -d 1 # 实时看进程内存占用 dmesg | tail -20 # 看是否出现 out of memory 相关的内核日志定位到是模型还是代码导致的内存增长然后针对性处理。4.5 现象五输入图像颜色错乱检测结果明显不对如果板端推理结果和 PC 端对不上先查三点图像的通道顺序BGR 还是 RGB、像素值范围0-255 还是 0-1、归一化参数是否一致。PaddlePaddle 训练时如果用的是 ImageNet 的mean[0.485,0.456,0.406], std[0.229,0.224,0.225]板端推理也要用一模一样的值。OpenCV 默认读进来是 BGR如果你的模型是按 RGB 训练的中间必须做cv::cvtColor转换。在板子上打印几个像素值和训练预处理后的结果对比一下这是最快的定位方式。5. 把算力花在刀刃上Edgeboard-FZ3B 上三个值得抠的细节5.1 比较检测框和实际位置之间的偏差做好延时补偿推理占用几十毫秒车在这段时间里已经往前跑了不短的距离。如果控制逻辑用的是上一帧的图像检测结果方向控制会有明显的滞后。常见做法是给检测结果加一个时间戳控制模块根据当前车速估算车的实际位置对检测框做位置补偿。具体到代码层面就是记录每一帧推理完成时车的速度然后根据这个速度修正目标点的横向偏差。// 延时补偿的核心逻辑 float speed_ms current_speed / 3.6; // km/h - m/s float latency infer_end_time - image_capture_time; // 单位秒 float distance_offset speed_ms * latency; // 车子在推理期间的行驶距离 // 用 distance_offset 修正检测框与车头的相对位置这个补偿不改变模型但能明显改善高速入弯时的控制平滑度。控制周期建议固定在 10ms 到 20ms并且要与推理线程解耦不要“推理阻塞就停发控制指令”否则会出现一段失去控制的时间窗口。5.2 用线程绑定把推理、采集、控制安排在不同 CPU 核心上FZ3B 的 ARM 侧有多个核心默认调度器不会帮你按“实时性优先级”分配核心。推理线程、摄像头采集线程、串口发送线程互相抢占 CPU会导致偶发的长延迟尖峰。#include sched.h #include unistd.h void bind_thread_to_core(int core_id) { cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(core_id, cpuset); sched_setaffinity(0, sizeof(cpuset), cpuset); }在线程入口调用bind_thread_to_core(0)、bind_thread_to_core(1)等把实时性要求最高的感知线程放到独立核心上其他业务放另外的核心。对于完全模型组来说推理是主循环占一个核图像采集和预处理占另一个控制输出和日志在一个低优先级线程。三个线程间用无锁队列或者带超时的双缓冲传递数据避免一把大锁锁住所有流程。5.3 把预处理里的“隐形成本”可视化很多人以为推理延迟就是模型本身的耗时实际上整条链路里imread、resize、normalize、数据拷贝每一项都可能比模型本身还贵。建议把每一段耗时打点打出来auto t0 std::chrono::steady_clock::now(); // 图像采集 auto t1 std::chrono::steady_clock::now(); // 预处理 auto t2 std::chrono::steady_clock::now(); // 推理 auto t3 std::chrono::steady_clock::now(); // 后处理 auto t4 std::chrono::steady_clock::now();连续记录 100 帧把各段耗时的中位数和 P99 报出来。如果发现 resize 或 normalize 占比过高常见做法是把 resize 和归一化合并在一个循环里、用 NEON 指令并行处理多个像素、或者直接把归一化参数合进模型的第一个卷积层省掉一次全图遍历。这些优化在 PC 上收益可忽略在板上却是实打实的每帧 5 到 10 毫秒。本文还有配套的精品资源点击获取
