2、环境准备：开发机、交叉编译工具链、依赖库、Python环境与SDK安装配置
地平线旭日系列（Sunrise）芯片的嵌入式开发，本质上是在资源受限的异构计算平台上完成算法部署与工程落地。与纯x86服务器端开发不同，旭日平台的开发环境搭建涉及宿主机（开发机）、目标板（嵌入式设备）与交叉编译工具链三者之间的协同。本章将系统梳理从零开始搭建完整开发环境的核心流程，涵盖开发机选型与系统配置、交叉编译工具链的安装与验证、依赖库的获取与编译、Python运行环境的构建，以及地平线AI SDK（如OE（OpenExplorer）工具链）的安装与配置。掌握本章内容，是后续进行模型转换、量化、编译与板端部署的前提条件。
上图展示了整个开发环境的物理与逻辑拓扑。开发机（x86架构）通过交叉编译工具链生成目标板（ARM架构）可执行的二进制文件，同时OE工具链负责将训练好的模型转换为地平线BPU可识别的指令集。下面我们将按照实际搭建顺序，逐一深入每个环节。
2.1 开发机选型与系统配置
核心原理：开发机是承载工具链、编译任务和模型转换的“主战场”。由于地平线OE工具链目前仅支持x86_64架构的Linux系统，且对CPU核数、内存大小有明确要求，因此开发机的性能直接决定了模型编译和量化校准的效率。选择开发机时，不仅要考虑当前项目的编译需求，还要为后续可能的多模型迭代预留余量。
推荐配置与判断方法：以下是经过验证的推荐配置，可作为选型参考：
| 配置项 | 最低要求 | 推荐配置 | 说明 |
|---|---|---|---|
| 操作系统 | Ubuntu 18.04 | Ubuntu 20.04 LTS / 22.04 LTS | 内核版本需≥4.15，OE工具链对glibc版本有依赖 |
| CPU | 4核 | 8核及以上 | 模型量化与编译为多线程任务，核数越多编译越快 |
| 内存 | 8GB | 16GB及以上 | 大模型（如YOLOv5s）转换时峰值内存可达6-8GB |
| 硬盘 | 50GB空闲 | 100GB SSD | OE工具链约占用5GB，依赖库源码与中间文件需预留空间 |
| GPU | 无要求 | 非必需 | 模型转换在CPU上完成，GPU仅用于训练阶段 |
操作流程：开发机系统准备分为以下步骤：
- 安装Ubuntu 20.04 LTS，分区时建议将
/home独立挂载，便于后续工具链与SDK的权限管理。 - 更新系统软件源并安装基础依赖：
sudo apt update sudo apt install -y build-essential cmake git wget unzip \ python3-dev python3-pip python3-venv libssl-dev \ libffi-dev libopenblas-dev libopencv-dev - 创建普通用户（避免使用root进行编译），并加入
dialout组以获取串口权限：sudo usermod -aG dialout $USER
2.2 交叉编译工具链安装与验证
核心原理：交叉编译是指在x86_64宿主机上编译生成ARM架构（aarch64）可执行代码的过程。旭日芯片采用ARM Cortex-A53/A55内核，因此必须使用aarch64-linux-gnu-前缀的GCC工具链。工具链中除了编译器，还包含目标板的系统库（sysroot），确保链接时能找到正确的libc和内核头文件。
安装方法：地平线官方推荐使用Linaro提供的工具链，也可通过apt直接安装：
# 方法一：apt安装（版本较新，推荐）
sudo apt install -y gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
# 方法二：Linaro官方工具链（版本可控）
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz
sudo tar -xvf gcc-linaro-*.tar.xz -C /opt/
export PATH=/opt/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin:$PATH验证工具链：编写一个简单的Hello程序并交叉编译，然后通过file命令检查生成文件的架构：
# test.c
#include <stdio.h>
int main() { printf("Hello Horizon!\n"); return 0; }
# 编译
aarch64-linux-gnu-gcc test.c -o test_arm
# 验证
file test_arm
# 输出应包含: ELF 64-bit LSB executable, ARM aarch64toolchain.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)2.3 依赖库的获取与交叉编译
核心原理：板端应用通常依赖OpenCV、protobuf、sqlite3等第三方库。由于目标板存储空间有限且不便现场编译，这些库必须在开发机上完成交叉编译后，随应用一起部署。依赖库的编译需要指定与工具链匹配的交叉编译参数，否则会出现“找不到头文件”或“架构不匹配”的错误。
编译流程（以OpenCV为例）：
- 下载OpenCV源码（推荐4.x版本）：
git clone --branch 4.5.5 --depth 1 https://github.com/opencv/opencv.git - 创建交叉编译脚本并执行：
cmake -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \ -DCMAKE_INSTALL_PREFIX=/opt/opencv-arm \ -DWITH_GTK=OFF -DWITH_QT=OFF -DWITH_V4L=ON \ -DBUILD_SHARED_LIBS=ON .. make -j8 make install - 将
/opt/opencv-arm目录打包，后续通过NFS或scp拷贝至目标板。
CMAKE_SYSTEM_PROCESSOR为aarch64，且CMAKE_FIND_ROOT_PATH指向目标板的sysroot路径。若目标板使用Buildroot或Yocto构建系统，建议直接使用其提供的工具链和库，避免版本冲突。
2.4 Python环境与SDK安装配置
核心原理：地平线OE工具链（包括模型转换、量化、编译工具）以Python包形式分发，依赖特定的Python版本和第三方库。同时，板端推理也需要Python运行时（如hobot_python），但板端Python环境与开发机相互独立。因此，需要在开发机上创建独立的Python虚拟环境，避免与系统Python冲突。
开发机Python环境搭建：
# 创建虚拟环境
python3 -m venv horizon_env
source horizon_env/bin/activate
# 安装OE工具链（以X3芯片为例）
pip install horizon_oe_py-*.whl
pip install horizon_tc_ui-*.whl
# 验证安装
hb_mapper --helpSDK目录结构说明：安装完成后，OE工具链会在/opt/horizon下生成以下关键目录：
| 目录/文件 | 作用 |
|---|---|
/opt/horizon/lib | 板端运行时库（libdnn.so, libhbrt.so等） |
/opt/horizon/include | C/C++头文件，用于应用开发 |
/opt/horizon/tools | 模型转换、性能分析等命令行工具 |
/opt/horizon/models | 预编译的示例模型（.bin格式） |
板端Python环境（可选）：若需在板端运行Python推理脚本，可通过pip安装地平线提供的hobot_dnn包：
# 在目标板上执行
pip3 install hobot_dnn-*.whl
python3 -c "from hobot_dnn import pyeasy_dnn; print('DNN OK')"2.5 案例拆解：从零搭建YOLOv5部署环境
背景与目标：某安防项目需要在旭日X3开发板上部署YOLOv5s目标检测模型。开发团队从零开始搭建环境，要求在3天内完成从环境准备到模型转换的全流程验证。
初始条件与约束：团队使用一台8核16GB内存的Ubuntu 20.04开发机，目标板为旭日X3开发套件（2GB内存版本）。模型为YOLOv5s（COCO预训练权重），输入尺寸640×640。
实施过程：
- 开发机准备：安装Ubuntu 20.04，配置清华源，安装基础依赖（耗时约1小时）。
- 工具链安装：通过apt安装gcc-aarch64-linux-gnu，并验证编译Hello程序（耗时20分钟）。
- 依赖库编译：交叉编译OpenCV 4.5.5（关闭GUI模块，仅保留core/imgproc/imgcodecs），耗时约40分钟。同时编译protobuf 3.12.4用于后续模型解析。
- Python环境：创建venv，安装OE工具链（版本为1.1.8），并安装onnx、numpy等依赖（耗时30分钟）。
- 模型转换：将YOLOv5s导出为ONNX，使用
hb_mapper进行量化校准（使用100张COCO验证集图片），生成yolov5s.bin（耗时约2小时）。 - 板端部署：将编译好的可执行文件、OpenCV库和模型拷贝至目标板，通过
hobot_dnn加载模型进行推理测试。
结果与复盘：最终在板端实现了约30FPS的推理速度（单核BPU），满足项目实时性要求。复盘发现，最初直接使用系统Python导致OE工具链与系统库冲突，改用venv后问题解决。此外，OpenCV编译时未开启NEON优化，导致图像预处理耗时偏高，后续通过添加-mcpu=cortex-a53 -mfpu=neon编译参数将预处理时间缩短了30%。
2.6 常见误区与总结复盘
误区一：使用root用户进行编译。OE工具链在root权限下可能无法正确识别部分环境变量，且编译产物权限混乱。应始终使用普通用户，并通过sudo仅对安装步骤提权。
误区二：忽略sysroot的版本匹配。工具链的glibc版本必须低于或等于目标板系统的glibc版本，否则会出现“cannot find -lc”或运行时“version `GLIBC_2.34' not found”错误。建议在目标板上执行ldd --version确认版本。
误区三：在Windows/Mac上直接解压SDK。OE工具链中的脚本包含Linux符号链接，在Windows解压会破坏链接关系。应在Linux环境下解压，或使用tar命令保留链接属性。
误区四：板端Python与开发机Python混用。板端是ARM架构，开发机是x86架构，两者pip包不通用。必须分别安装对应架构的whl包。