第一章 课程导入：学习目标、适用人群与地平线旭日平台整体交付流程概览

地平线旭日（Sunrise）系列芯片作为国产边缘人工智能计算平台的主力军，广泛应用于智能摄像头、机器人、车载感知、工业质检等场景。本章作为整个交付课程的开篇，旨在帮助学员建立对旭日平台交付工作的全局认知：明确学完本课程后能解决哪些实际问题、适合谁来学、以及一套标准化的交付流程包含哪些关键环节。我们将从交付工程师的视角，梳理从拿到开发板到最终量产部署的完整链路，为后续章节中关于模型转换、镜像烧录、脚本编写和部署优化的深入学习奠定框架基础。

上图展示了旭日平台交付的四个核心阶段及其产物关系。从环境准备到最终部署，每个阶段都有明确的输入输出和验证节点（TP1-TP3）。值得注意的是，整个流程并非单向线性，而是存在从部署阶段回退到模型或镜像阶段的迭代循环，这在实际项目中非常常见。接下来，我们将详细拆解本章的学习目标、适用人群以及各阶段的关键任务。

1.1 学习目标：从“能跑通”到“交付好”

本课程不是简单的“板卡使用教程”，而是面向工业级交付的实战指南。学完本课程，学员应具备以下核心能力：

• 掌握模型转换全链路：能够将PyTorch/TensorFlow/ONNX模型通过地平线工具链（如OE（OpenExplorer）工具链）转换为旭日芯片可执行的指令文件，并完成INT8量化与精度评估。
• 独立构建系统镜像：能够基于旭日BSP（Board Support Package）定制Linux内核、设备树、根文件系统，并制作可量产烧录的镜像文件。
• 编写高效部署脚本：能够编写Python/C++部署脚本，实现模型加载、推理调度、前后处理、日志监控等功能，并针对旭日平台的多核CPU与BPU（Brain Processing Unit）进行异构计算优化。
• 建立交付调试方法论：面对启动失败、性能瓶颈、精度损失等问题，能够通过日志分析、硬件调试工具（串口、JTAG）和性能剖析工具快速定位根因。

1.2 适用人群：谁需要这门课程？

本课程内容深度与广度兼顾，适合以下三类核心人群：

人群类型	典型背景	课程收益
嵌入式Linux工程师	熟悉ARM平台、U-Boot、内核裁剪，但对AI模型转换不熟悉	补齐模型转换与BPU部署知识，实现从传统MCU/Linux开发向AIoT开发转型
算法/软件工程师	熟悉PyTorch/TensorFlow，但对交叉编译、镜像烧录、硬件调试不熟悉	理解模型在边缘芯片上的落地约束，掌握量化、算子映射及性能调优方法
项目交付/技术支持工程师	负责客户项目落地，需要处理现场环境适配、版本管理、问题复现	建立标准化交付流程意识，掌握日志采集、镜像备份、脚本化部署等实用技能

此外，对边缘计算感兴趣的高年级学生或硬件爱好者，也可以将本课程作为系统学习国产AI芯片开发的人门路径。课程默认学员具备基本的Linux命令行操作能力（如文件操作、vim编辑、tar打包），并了解Python或C++的基本语法。

1.3 地平线旭日平台整体交付流程概览

一个完整的旭日平台项目交付，通常遵循“四阶段八步骤”的框架。以下流程基于实际项目经验总结，适用于智能摄像头、边缘计算盒子等典型场景。

阶段一：环境准备与工具链验证

1. 硬件准备：确认开发板型号（如旭日X3派、旭日X5开发盒）、电源适配器（12V/2A以上）、串口线（USB转TTL）、网线或Wi-Fi模块。
2. 开发环境搭建：在x86主机上安装Ubuntu 20.04/22.04系统，配置交叉编译工具链（如aarch64-linux-gnu-gcc）、地平线OE工具链（包含模型转换器、编译器、运行时库）。
3. 最小系统启动验证：烧录官方预编译镜像，确认系统能正常启动，串口输出无异常报错，网络连通。

阶段二：模型转换与精度验证

1. 模型预处理：将训练好的模型导出为ONNX格式，并固定输入尺寸（如640x640）。注意：旭日BPU对动态尺寸支持有限，建议固定分辨率。
2. 模型转换与量化：使用OE工具链的hb_mapper工具，将ONNX模型转换为静态图，并执行INT8量化。量化需要准备校准数据集（通常500-1000张代表性图片）。
3. 精度与性能评估：在开发板上运行转换后的模型，对比原始浮点模型与量化模型的精度差异（如mAP下降不超过1%），并测试单帧推理延迟。

阶段三：系统定制与镜像制作

1. 内核与设备树调整：根据实际外设（如摄像头传感器型号、GPIO扩展芯片）修改设备树源文件（.dts），重新编译内核或使用模块加载方式。
2. 根文件系统定制：基于Ubuntu Base或Buildroot制作rootfs，安装必要的运行库（如libopencv、libjson-c）、部署脚本及模型文件。
3. 镜像打包与烧录：使用mkimage工具将内核、设备树、rootfs打包为完整的烧录镜像（如.img文件），并通过rufus或dd命令写入SD卡或eMMC。

阶段四：部署脚本编写与联调

1. 应用层开发：编写主程序，负责初始化BPU、加载模型、采集图像（通过V4L2或RTSP）、执行推理、后处理（如NMS）、结果上报（MQTT/HTTP）。
2. 性能调优：使用perf、top、地平线提供的hrt_tools分析CPU/BPU占用率，优化多线程流水线（如双缓冲、零拷贝）。
3. 压力测试与日志收集：进行7x24小时连续运行测试，记录系统日志（dmesg、syslog）、应用日志，并验证异常重启后的自恢复能力。

1.4 案例拆解：从零开始交付一台AI边缘计算盒子

为了将上述流程具象化，我们以一个典型的“工厂质检AI盒子”项目为例进行拆解。该项目的目标是替代传统人工目检，实现PCB板表面缺陷的实时检测。

项目背景与约束：客户现场环境温度较高（40℃），要求设备体积小、无风扇散热；检测节拍要求小于200ms/片；需要对接客户已有的MES系统，通过Modbus TCP上报检测结果。硬件选型为旭日X3派开发板（4GB内存版本），搭配500万像素全局快门工业相机。

初始现象与目标：算法团队提供了一个基于YOLOv5s的缺陷检测模型，在GPU服务器上mAP达到0.95。目标是在旭日平台上实现mAP≥0.92，且单帧处理时间≤180ms。

关键输入数据与参数：

• 模型输入尺寸：640x640x3，输出为3个尺度的检测头。
• 校准数据集：800张包含不同光照、不同缺陷类型的PCB图像。
• 目标硬件资源：BPU算力约5 TOPS，CPU为4核Cortex-A53。

分析判断过程：首先，我们使用OE工具链的hb_mapper checker工具检查模型算子兼容性，发现YOLOv5s中的Focus层和SiLU激活函数在BPU上支持效率较低。于是，我们决定将Focus层替换为普通的Conv层（通过修改模型结构并重新训练），并将SiLU替换为ReLU6（精度损失约0.3%，但推理速度提升15%）。

实际操作步骤：

1. 在GPU服务器上修改模型结构并微调训练，导出ONNX。
2. 使用hb_mapper makertbin命令进行INT8量化，量化策略选择“per-channel”，并开启“数据增强”选项以提升鲁棒性。
3. 在开发板上运行转换后的模型，实测mAP为0.93，满足要求；但推理延迟为210ms，超出目标。
4. 进一步分析发现，瓶颈在于图像前处理（BGR转RGB、归一化）使用了CPU。我们利用旭日平台的hbdk运行时库，将前处理操作合并到BPU计算图中（通过自定义算子），最终延迟降至165ms。

结果对比与复盘：最终交付的镜像包含定制内核（启用了看门狗）、优化后的模型文件、以及一个约500行的Python部署脚本（使用multiprocessing实现采集/推理/上报流水线）。在7天连续运行测试中，设备在45℃环境温度下稳定运行，未出现死机或内存泄漏。复盘经验：模型结构的硬件友好性改造往往比盲目调优更有效；前处理与后处理的上板优化是性能达标的关键。

1.5 常见误区与总结复盘

在多年交付经验中，我们总结了以下高频误区，希望学员在后续学习中引以为戒：

• 误区一：忽视工具链版本一致性。开发主机上的OE工具链版本必须与开发板上运行的运行时库（hbrt）版本严格对应。否则会出现“模型转换成功但加载失败”的诡异问题。建议使用hb_mapper --version和板上hbrt_version命令核对。
• 误区二：镜像烧录后不做启动日志留存。很多工程师烧录后看到屏幕无输出就认为失败，实际上可能是串口波特率设置错误（旭日平台默认1500000bps）。务必使用串口工具（如MobaXterm）连接并保存完整启动日志。
• 误区三：脚本编写不考虑异常恢复。部署脚本应包含看门狗喂狗逻辑、关键进程守护（如使用systemd服务）、日志轮转机制。否则现场设备运行数月后可能因日志文件过大导致存储满而崩溃。
• 误区四：忽略散热与功耗验证。旭日X3派在高负载推理时芯片温度可达85℃以上，若机箱散热不良会触发降频，导致推理延迟翻倍。交付前必须在极限负载下进行温度测试。