搞嵌入式这块板子之前我手里 Microduck-HD1910 已经跑了三个多月真实项目从裸板到能稳定跑通 YOLOv5s 检测再到把检测结果上报云端做大模型语义理解这条“模型部署、硬件调试、软件开发”完整链路踩过的坑比想象中多得多。这篇教程我尽量把手把手的细节写清楚为什么选 HD1910、环境怎么搭、模型怎么从 PyTorch 转到 NPU、板子调不稳怎么办、上层业务代码怎么写每个环节都给出能直接抄作业的命令和代码。适合三类人看想入门边缘 AI 的嵌入式工程师、要把算法落地到端侧的算法工程师、以及准备做毕业设计或竞赛项目的学生开发者。先提醒一句Microduck-HD1910 不是什么高性能服务器它是典型的边端 AI 设备。你要在这块板子上部署的不是大语言模型而是目标检测、分类、分割这类视觉模型。大模型更多是放云端或者本地服务器HD1910 负责端侧实时处理两者配合着用。把这个定位想清楚后面所有技术选型就顺了。1. 为什么选 Microduck-HD1910一块为边端AI而生的板子1.1 HD1910的硬件底子与定位HD1910 这块板子从形态上就是个巴掌大的嵌入式计算板核心是四核 Cortex-A7 架构的 SoC主频 1.5GHz 左右板载 NPU 算力标称 2TOPSINT8。我手上这款是 2GB 内存 16GB eMMC 的版本另外还有 512MB 和 1GB 内存的阉割版买的时候别贪便宜做 AI 推理建议直接上 2GB 版本。接口方面一路千兆以太网、两个 USB一个 3.0 一个 2.0、双 MIPI-CSI 摄像头接口、一个 MIPI-DSI 屏幕接口还有 40Pin GPIO 扩展排针基本覆盖了智能硬件原型开发的所有需求。系统可以跑精简版 Ubuntu 或者厂商提供的 Buildroot 固件我最终用的是 Ubuntu 22.04 用户态镜像因为后面要跑 Python 推理脚本和 MQTT 服务Buildroot 模式虽然轻量但装包太痛苦。2TOPS 这个算力听起来不大但实际跑 YOLOv5s 输入 640×640 分辨率INT8 量化后 NPU 推理大概能到 25–35ms 一帧加上前后处理整体帧率能做到 15–20FPS对于很多工业检测、巡检机器人、智能门禁场景已经够用了。作为对比同样在 HD1910 上纯 CPU 跑 YOLOv5s一帧要 250ms 起步完全没法实时。这就是为什么选带 NPU 的板子而不是普通开发板的核心原因——NPU 决定了你能不能把模型真正用起来。1.2 和树莓派5、Hi3516CV610这类板子怎么取舍很多朋友问我为啥不直接上树莓派5我拿 HD1910 和几个典型平台对比一下维度Microduck-HD1910树莓派5Hi3516CV610算力形态四核A7 2TOPS NPU四核A76无NPU有NPU强视频编解码AI推理能力INT8量化后跑YOLO约30msCPU推理约200–300ms可外接加速棒视觉模型优化好但SDK较封闭系统生态Linux用户态Python/C均可Linux生态极其完善LiteOS/Linux工具链配置繁琐开发门槛低开箱即用极低但端侧推理性价比一般较高适配周期长典型场景边缘AI原型/小规模量产通用计算、桌面级应用摄像头模组、量产IPC产品树莓派5 强在 CPU 和生态写应用、做服务器都行但没有内置 NPU纯 CPU 跑深度学习模型很吃力。你可以外接 USB 加速棒但多一个设备就多一份不稳定供电和散热都更麻烦。Hi3516CV610 是海思的视觉方案做安防摄像头很强SDK 和工具链更适合有量产经验的团队学生或独立开发者直接上手会比较难受。HD1910 恰好卡在中间有 NPU、有完整的 Linux 生态、GPU 不需要你碰买回来插电就能开始写代码。注意如果你要部署的是大语言模型比如 Qwen2.5-7BHD1910 的内存和算力都撑不住老老实实放服务器。它的定位是端侧小模型推理不是本地大模型平台。2. 环境搭建从零开始把裸板跑起来2.1 串口烧录与首次启动拿到 HD1910 第一件事不是写代码而是先把系统烧进去、确认串口能通。这块板子支持 USB 烧录和 TF 卡烧录两种方式我强烈推荐用 USB 烧录速度稳定且不需要额外准备读卡器。准备工作一根 Micro USB 线要能传输数据的不是充电线、一根 USB 转 TTL 串口线推荐 CP2102 芯片的驱动全平台通用、5V/3A 电源适配器。先别急着上电把板子背面的启动拨码开关拨到“USB烧录”档位按住板上的 Download 按键不放同时接上 USB 线到电脑。电脑上会弹出一个新的 USB 设备Linux 系统下可以用lsusb确认lsusb # 正常会看到类似ID 2207:180a 的Rockchip设备这里多说一句原理HD1910 的 SoC 内置了 MaskROM 引导程序上电时如果检测到 Download 引脚被拉低就会进入烧录模式等待宿主机发数据。所以每次烧录前必须保证按键时序正确——先按 Download再上电或插入 USB顺序反了就只能重新断电再来。接着打开官方烧录工具加载厂商提供的统一固件后缀通常是.img点“烧写”后大概两三分钟就完成了。烧完把拨码拨回正常启动位接上串口线注意 TX 接 RX、RX 接 TX、GND 接 GND电源上电串口终端里应该能看到 U-Boot 打印和内核日志sudo apt install minicom sudo minicom -s # 进入配置串口设备选 /dev/ttyUSB0波特率 115200数据位8停止位1无校验看到内核启动日志以后系统应该会自动进到 Ubuntu 的命令行登录界面默认账号 root密码自己从厂商文档里找。首次进系统第一件事就是扩容根分区出厂镜像的根分区一般只占了一小部分 eMMC 空间df -h # 然后用 parted 或厂商提供的一键扩容脚本扩展分区这一步很多人忽略结果用两天发现磁盘满了。HD1910 的 eMMC 出厂预装了 16GB但根分区默认只分了 2GB剩下的空间是未分配状态不扩容就是个定时炸弹。2.2 开发机交叉编译与板端网络连接HD1910 性能有限直接在板子上编译大型程序会等到怀疑人生。我的习惯是在笔记本上做交叉编译或者直接在板子上编译小体量程序大工程全部交叉编译再传上去。装交叉工具链sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu写 CMake 交叉编译工具链文件toolchain-aarch64.cmakeset(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_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)编出来的可执行文件用scp传到板子上scp ./build/demo root192.168.1.100:/root/开发机到板子的网络打通很关键。HD1910 的千兆网口直连路由器然后开发机 SSH 上去。为了让开发体验接近本地我在 VSCode 里装了 Remote-SSH 插件直接把整个工程作为远程文件夹打开编辑、保存、终端操作都在板子上完成延迟极低。另外条件允许的话我建议配一个 Samba 共享目录把板子的/opt共享到开发机这样编译输出和素材传输能省掉大量 scp 操作sudo apt install samba sudo vi /etc/samba/smb.conf # 添加 [develop] 段path/optwritableyes这套环境搭完之后开发效率会有一个质的提升。前两三天磨刀不误砍柴工后面调试模型和业务代码时就会觉得顺手很多。3. 模型部署实战从YOLOv5到NPU推理3.1 模型转换流水线PyTorch - ONNX - RKNN模型部署是整个项目的核心。我以 YOLOv5s 为例讲完整的转换链路你在自己训练的模型上照搬即可。HD1910 的 NPU 用的是瑞芯微的工具链也就是 RKNN-Toolkit2 那一套所以转换流程是PyTorch训练权重 - ONNX - RKNN格式。首先在 PC 上用官方仓库导出 ONNXpython export.py --weights yolov5s.pt --include onnx --opset 12导出之后强烈建议先用onnxsim做一次简化把 BN 融合、常量折叠这些优化做掉pip install onnxsim python -m onnxsim yolov5s.onnx yolov5s-sim.onnx然后安装 RKNN-Toolkit2PC端工具包写转换脚本from rknn.api import RKNN rknn RKNN() # 重点mean_values 和 std_values 要和训练时的预处理一致 rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk1106 ) rknn.load_onnx(modelyolov5s-sim.onnx) # 量化需要dataset.txt每行一张用于校准的图片路径建议300~500张覆盖真实场景 rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(yolov5s.rknn)这里有几个我踩过的大坑必须强调第一mean_values和std_values不能拍脑袋填。YOLOv5 训练时默认预处理是把像素除以 255所以 mean0、std255 是对的。如果你训练时用了自己的归一化参数转换时不一致模型精度会直接雪崩甚至检测框完全乱飞。第二INT8 量化必须用有代表性的校准图片。我第一版量化随便拿了 50 张网上下的图片做的校准结果模型在真实场景里置信度普遍下降 20%换了 300 张现场拍的照片重新量化后才恢复正常。校准集决定了量化后模型的分布多花点时间整理图片绝对值得。第三RKNN版本要严格匹配PC 端用哪个版本转换出的 rknn 文件板端 runtime 就得上对应版本的 RKNNLite。版本不一致最常见的表现就是初始化失败或者推理结果错乱排查方式后面单独讲。3.2 板端推理Python快速原型和C测帧率HD1910 板端推理最简单的方式是用 RKNNLite 的 Python API。先pip install rknnlite板端安装包从厂商手里拿然后写推理脚本import cv2 import numpy as np from rknnlite.api import RKNNLite rknn_lite RKNNLite() rknn_lite.load_rknn(yolov5s.rknn) rknn_lite.init_runtime() img cv2.imread(test.jpg) # letterbox缩放保持宽高比填充114 scale, offset letterbox(img, (640, 640)) input_tensor img / 255.0 input_tensor input_tensor.transpose(2, 0, 1).astype(np.float32) input_tensor np.expand_dims(input_tensor, axis0) outputs rknn_lite.inference(inputs[input_tensor]) # outputs 的形状一般是 [1, 25200, 85] boxes postprocess(outputs[0])不少人在预处理这步翻车直接把cv2.resize把 1080p 图片压到 640×640没有做 letterbox导致画面被拉伸变形检测框位置全错。YOLOv5 后处理解码时隐含了 letterbox 带来的坐标偏移所以输入侧必须保证同样的缩放方式。letterbox 的填充值用 114这是 YOLOv5 训练时默认的别改改了模型同样会掉精度。推理后处理部分是个体力活本质就是解析 YOLO 输出的[25200, 85]矩阵前 84 维是类别概率最后 1 维是置信度用阈值过滤低分框再用 NMS 去除重复框。这些逻辑直接用 ultralytics 的官方后处理改一版即可我建议一开始别自己重写 NMS先用官方代码跑通再考虑性能优化。确认 Python 版本结果正常后要上 C 测真实帧率。用 C 主要是两个原因一是 Python 的预处理在 CPU 上耗时占比太高二是后续接入摄像头和视频流转发C 比 Python 稳得多。CMake 里关键部分find_package(OpenCV REQUIRED) target_link_libraries(detect rknn_api ${OpenCV_LIBS} pthread)C 端的 RKNN API 和 Python 很接近rknn_init加载模型rknn_inputs_set传输入rknn_run推理rknn_outputs_get取输出。实测下来 Python 端一帧推理前后处理约 45msC 端可以压到 30ms 以内差距主要来自预处理。如果你是做实时视频流务必用 C。3.3 可视化部署训练曲线、推理界面和视频推流模型部署完成之后“可视化”是大多数人忽略但极其关键的环节。不是说模型跑通了就万事大吉你要能看到它跑得怎么样。训练阶段的可视化用 TensorBoard 就够了python train.py tensorboard --logdirruns浏览器打开http://localhost:6006能看到 loss 曲线和 mAP 曲线。这是判断训练是否收敛的最直观方式。推理阶段的可视化我用 Gradio 搭了一个 Web 演示界面手机和电脑都能直接访问非常适合项目汇报和现场测试import gradio as gr def detect_image(img): boxes run_inference(img) draw_img draw_boxes(img, boxes) return draw_img gr.Interface( fndetect_image, inputsgr.Image(typenumpy), outputsgr.Image(typenumpy) ).launch(server_name0.0.0.0, server_port7860)在 HD1910 上跑 Gradio 不会占用太多资源它的作用只是验证模型效果不是生产级服务。另外如果想把摄像头实时画面推到 Web 端看可以直接用 ffmpeg 推 RTSP 流ffmpeg -f v4l2 -i /dev/video0 -c:v h264_omx \ -b:v 2000k -f rtsp -rtsp_transport tcp rtsp://0.0.0.0:8554/live.sdp这里要提醒一下HD1910 跑 ffmpeg 推流时 CPU 占用会明显上升如果同时还跑推理建议把编码分辨率降到 720p否则整体帧率会被拖下来。做边缘 AI 项目资源永远要先保证推理核心任务。经验之谈模型部署阶段的“可视化”解决的是信任问题。老板、客户、合作方看到可视化界面才相信模型真的能工作。项目交付前花一晚上把可视化界面做好比多调几个百分点 mAP 更管用。4. 硬件调试把“跑不起来”变成“稳定跑”4.1 常用调试工具与接线板子跑起来之后硬件调试才是真正拉开新手和老手差距的地方。HD1910 的硬件调试主要围绕四类工具串口、JTAG、逻辑分析仪、万用表。串口是最基础也最常用的调试手段。Linux 下内核崩溃、驱动加载失败、应用异常都能在串口终端里看到 log。比如摄像头初始化失败时串口里通常会有类似mipi csi: failed to probe sensor之类的报错这比对着代码猜要快得多。JTAG 用于低层调试比如裸机程序、U-Boot、内核早期的初始化问题。HD1910 上引出的是标准 ARM JTAG 接口用 J-Link 加 OpenOCD 可以做断点调试和寄存器查看。但说句实话大部分 AI 应用层开发用不到 JTAG除非你在调试 U-Boot 或者自己写的内核驱动。逻辑分析仪是我这次项目里用得最多的工具。调试 MIPI 摄像头时图像一直黑屏我第一反应就是用逻辑分析仪去抓摄像头和控制器的 I2C 通信波形确认 sensor 的 ID 有没有读回来。如果 SCL 有正常时钟但 SDA 没有 ACK说明 sensor 的 I2C 地址不对或者供电没起来。这类问题靠看代码基本无解抓波形一抓一个准。接线有个万年级的坑串口 TX/RX 接反。USB 转 TTL 线标注的 TX 要接板子的 RX线标注的 RX 要接板子的 TXGND 必须共地。接反的典型现象是终端里完全没输出或者输出乱码。另外 USB 转 TTL 线芯片也分两种CP2102 和 CH340 的驱动都能在 Linux 内核里找到如果dmesg | grep tty看不到新设备大概率是线坏了或者驱动没装。4.2 供电、散热、时序与信号完整性问题HD1910 上最常见的一类稳定性问题根源都在供电。官方说支持 5V/3A但我一开始图省事用了一个 5V/2A 的旧充电头结果板子在高负载推理时频繁重启。查串口日志最后只看到干干净净的“suddenly reboot”没有任何异常输出。换 5V/3A 电源后问题立刻消失。这里解释一下原因NPU 满负载运行时瞬间电流可能冲到 2.5A 以上劣质电源电压跌落幅度过大SoC 内部电源监控电路检测到欠压就强行复位。更坑的是劣质 USB 线也有压降线长超过一米且线径细的话就算电源标称 3A到板端实际电压也只剩 4.6V 左右。散热同样不能忽视。HD1910 运行 YOLOv5s 推理二十分钟后SoC 表面温度可以到 70℃ 以上。芯片温度过高时 NPU 会主动降频表现出来的特征就是帧率刚开始正常越跑越慢。我加了散热片加 5V 风扇主动散热后温度稳定在 52℃ 左右推理帧率一路稳定不掉。时序问题在调试外设时经常遇到。HD1910 上接的一些传感器模组要求上电顺序严格先给模组供电再初始化 I2C。如果代码里把初始化跑在模组上电稳定之前模组就会应答一个错误状态。解决办法是在初始化之前加延时或者用单片机 GPIO 控制模组供电时序。HD1910 有 40Pin GPIO完全可以用一个 GPIO 做外设电源开关代码里先拉高 GPIO延时 100ms再去做设备探测。4.3 常见故障排查实录一张实用的速查表做这个项目的三个月里我攒了一份 HD1910 的排障记录整理出来供参考故障现象可能原因排查手段频繁重启供电不足、电源线压降过大、过热换5V/3A电源和短线加散热风扇串口看最后一条日志串口无输出TX/RX接反、波特率错误、驱动未装、线材坏更换串口线确认115200 8N1dmesg看tty设备推理结果全黑或框乱飘预处理归一化不一致、通道顺序RGB/BGR错误检查mean/std/scale值打印输入tensor前几个像素做对比模型加载失败RKNN版本不匹配、模型文件损坏查PC端RKNN版本和板端RKNNLite版本重新导出rknnUSB摄像头无法识别内核缺少UVC驱动dmesg看内核报错重新编译内核模块NPU推理帧率越来越慢过热降频、内存碎片查看温度重启应用观察是否恢复增加内存清理逻辑I2C设备探测不到地址错误、上电时序不对、上拉电阻问题逻辑分析仪抓波形用 i2cdetect -y 扫描地址排查的通用思路是“从物理层到应用层”先确认电有没有供对再确认通信波形对不对再确认驱动有没有加载最后才检查应用代码。很多人一上来就翻应用日志结果浪费大量时间问题其实在电源线。5. 上层软件开发让边缘端真正服务于业务5.1 应用层服务架构推理加MQTT加Web API模型在 HD1910 上稳定推理之后接下来要考虑的是怎么把它变成一个能用的产品而不只是一个“能跑 demo 的板子”。我的做法是搭一套轻量服务架构摄像头采集画面 - NPU 推理得到结构化数据 - 业务逻辑判断 - MQTT 上报到云端 - Web 可视化。数据流向大概是这样的Camera → 推理节点 → 业务过滤 → MQTT发布 → 云端订阅/存储 → Web展示HD1910 上跑 MQTT 客户端用 Python 的 paho-mqtt 库就行import paho.mqtt.client as mqtt client mqtt.Client(hd1910_device_001) client.connect(192.168.1.50, 1883, 60) # 检测到目标时发布事件 client.publish(device/001/detect, payload{type: person, conf: 0.92, ts: 2025-01-01 10:00:00})这里有个设计原则值得强调不要在边缘端上传整张图片或视频流除非网络条件特别好。更合理的做法是上传“检测结果的结构化描述”比如目标类别、置信度、坐标、时间戳。这样即使设备成千上万台云端也只接收文本数据负载极低。只有在需要人工复核的场景才把检测框截图压缩后上传比如 JPEG 质量压到 80一张图也就几十 KB。Web 端展示可以用 Node-RED 或者简单的 Flask 应用订阅 MQTT实时显示检测事件。HD1910 本身可以开发一个轻量 Web API对外暴露推理接口方便其他系统集成from flask import Flask, request, jsonify app Flask(__name__) app.route(/detect, methods[POST]) def detect(): img request.files[image].read() # 调用NPU推理封装 result run_inference(img) return jsonify(result)Flask 在 HD1910 上跑很轻松请求量不大时完全没问题。如果并发要求高建议换 gunicorn 或直接上 C 的 HTTP 框架。5.2 端上检测加云端大模型理解小模型和大模型分工HD1910 跑不了大语言模型但可以作为一个“眼睛”和大脑配合。我正在做的项目就是端侧 YOLOv5 检测到人员/车辆事件后把结构化描述发给云端的大语言模型让大模型生成自然语言的安全告警说明再推送给管理员。这样既保证了端侧实时性又借用了大模型的语义理解能力。云端部署大模型我用的是 Ollama 跑 Qwen2.5-7B官方仓库直接拉模型就能跑无需额外写推理代码ollama pull qwen2.5:7b ollama run qwen2.5:7b也可以用 vLLM 做并发更高的部署生产环境更推荐后者docker 起一个 vllm 服务docker run --gpus all -p 8000:8000 \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5HD1910 这边通过 HTTP 请求调用云端的 OpenAI 兼容接口import requests def generate_report(detect_info): prompt f根据以下检测结果生成一条简洁的安全告警消息{detect_info} resp requests.post( http://192.168.1.100:8000/v1/chat/completions, json{ model: qwen2.5, messages: [{role: user, content: prompt}] }, timeout10 ) return resp.json()[choices][0][message][content]这种“端侧小模型 云端大模型”的组合是目前边缘 AI 项目里很实用的架构。关键要控制调用频率不是每一帧都请求大模型而是检测到特定事件才触发否则云端压力大端侧也会因为等待响应卡死。注意大模型部署到云服务器上模型下载和依赖安装都比较繁琐建议先本地跑通 Ollama 单机方案再迁移到 vLLM 生产方案。另外模型文件的版本要和推理代码保持一致不同量化等级的输出风格差异还挺大的。5.3 边缘AI项目的交付经验稳定性、日志和自动化启动最后讲一点交付层面的事这些经验来自我实际被用户“坑”之后的反思。边缘设备不像服务器有人天天盯着它一旦装到现场就必须自己稳定运行无人值守。第一件事开机自启动用 systemd不要往/etc/rc.local里塞脚本。写一个 service 文件[Unit] DescriptionHD1910 Edge AI Service Afternetwork.target [Service] ExecStart/opt/edge_service/start.sh Restartalways RestartSec5 [Install] WantedBymulti-user.target为什么用 systemd因为Restartalways能保证进程意外退出后自动拉起。服务挂掉几分钟没人管对业务可能就是一笔损失。第二件事日志必须轮转否则设备 storage 会被日志文件撑爆。配置logrotate/opt/edge_service/logs/*.log { daily rotate 7 compress missingok copytruncate }第三件事模型文件和代码版本要绑定记录。我习惯把模型的 md5 和 Git commit hash 一起写进日志的启动头这样现场出问题才能快速定位是什么时候、哪个版本导致的。有次现场模型效果异常所有配置都没动过最后查出来是运维同事远程更新了模型文件没人记录版本排查了两天。从那以后我强制要求所有模型文件名必须带版本号比如yolov5s_v3_int8.rknn而且旧模型不原地覆盖归档到models/archive/目录。第四件事网络掉线重连逻辑必须写。HD1910 现场的 Wi-Fi 信号不可能永远稳定MQTT 客户端要配置自动重连并且断线期间的事件要缓存到本地 SQLite重连后补发。不然网一抖数据就丢了业务侧看到的检测记录有缺口投诉就到你这来了。一些实际操作中形成的个人习惯最后分享几条我在这块板子上沉淀下来的实操习惯算不上方法论但确实帮我省了很多时间。第一新板子到手先不要碰任何 AI 应用先花半天时间做“压力测试”跑一个死循环让 CPU 和 NPU 满载观察温度和稳定性。如果这个阶段就频繁重启说明硬件、电源、散热有问题这时候排查成本最低。等你已经把模型和业务代码都部署上去了再查硬件故障就非常痛苦。第二所有环境变量统一写在/etc/profile.d/hd1910.sh里不要随手在 shell 里 export。现场设备重启后shell 里的 export 全部失效但应用又被 systemd 拉起来了结果应用找不到环境变量路径直接崩溃。这个坑我踩过两次后来把环境变量集中管理后这类问题彻底绝迹。第三模型转换和量化尽量在电脑上批量做不要天天在板子上折腾。我专门写了一个脚本把 PyTorch 权重转 ONNX、ONNX 转 RKNN、格式校验串成一条命令每次训练完一键产出板端模型。省下来的时间够多调两个晚上的参数。第四遇到诡异问题先录日志不要凭感觉猜。HD1910 的串口日志、内核日志、应用日志分别记录排查问题时按时间线对齐看。很多时候问题不在一块板子而是多块板子之间的个体差异没有日志做交叉对比就会一直原地打转。Microduck-HD1910 这块板子整体来说是一块很适合练手的边缘 AI 开发平台它让你能用较低的硬件门槛把“模型部署-硬件调试-软件开发”这条路完整走一遍。走完这条路之后再去看市面上的边缘 AI 产品就会发现它们内部也就是这几件事的组合。希望这篇教程能帮你在自己的项目上少踩几个坑尤其是别在我栽过的地方再栽一次。
HD1910边缘AI开发实战：YOLOv5模型部署、RKNN转换与硬件调试
搞嵌入式这块板子之前我手里 Microduck-HD1910 已经跑了三个多月真实项目从裸板到能稳定跑通 YOLOv5s 检测再到把检测结果上报云端做大模型语义理解这条“模型部署、硬件调试、软件开发”完整链路踩过的坑比想象中多得多。这篇教程我尽量把手把手的细节写清楚为什么选 HD1910、环境怎么搭、模型怎么从 PyTorch 转到 NPU、板子调不稳怎么办、上层业务代码怎么写每个环节都给出能直接抄作业的命令和代码。适合三类人看想入门边缘 AI 的嵌入式工程师、要把算法落地到端侧的算法工程师、以及准备做毕业设计或竞赛项目的学生开发者。先提醒一句Microduck-HD1910 不是什么高性能服务器它是典型的边端 AI 设备。你要在这块板子上部署的不是大语言模型而是目标检测、分类、分割这类视觉模型。大模型更多是放云端或者本地服务器HD1910 负责端侧实时处理两者配合着用。把这个定位想清楚后面所有技术选型就顺了。1. 为什么选 Microduck-HD1910一块为边端AI而生的板子1.1 HD1910的硬件底子与定位HD1910 这块板子从形态上就是个巴掌大的嵌入式计算板核心是四核 Cortex-A7 架构的 SoC主频 1.5GHz 左右板载 NPU 算力标称 2TOPSINT8。我手上这款是 2GB 内存 16GB eMMC 的版本另外还有 512MB 和 1GB 内存的阉割版买的时候别贪便宜做 AI 推理建议直接上 2GB 版本。接口方面一路千兆以太网、两个 USB一个 3.0 一个 2.0、双 MIPI-CSI 摄像头接口、一个 MIPI-DSI 屏幕接口还有 40Pin GPIO 扩展排针基本覆盖了智能硬件原型开发的所有需求。系统可以跑精简版 Ubuntu 或者厂商提供的 Buildroot 固件我最终用的是 Ubuntu 22.04 用户态镜像因为后面要跑 Python 推理脚本和 MQTT 服务Buildroot 模式虽然轻量但装包太痛苦。2TOPS 这个算力听起来不大但实际跑 YOLOv5s 输入 640×640 分辨率INT8 量化后 NPU 推理大概能到 25–35ms 一帧加上前后处理整体帧率能做到 15–20FPS对于很多工业检测、巡检机器人、智能门禁场景已经够用了。作为对比同样在 HD1910 上纯 CPU 跑 YOLOv5s一帧要 250ms 起步完全没法实时。这就是为什么选带 NPU 的板子而不是普通开发板的核心原因——NPU 决定了你能不能把模型真正用起来。1.2 和树莓派5、Hi3516CV610这类板子怎么取舍很多朋友问我为啥不直接上树莓派5我拿 HD1910 和几个典型平台对比一下维度Microduck-HD1910树莓派5Hi3516CV610算力形态四核A7 2TOPS NPU四核A76无NPU有NPU强视频编解码AI推理能力INT8量化后跑YOLO约30msCPU推理约200–300ms可外接加速棒视觉模型优化好但SDK较封闭系统生态Linux用户态Python/C均可Linux生态极其完善LiteOS/Linux工具链配置繁琐开发门槛低开箱即用极低但端侧推理性价比一般较高适配周期长典型场景边缘AI原型/小规模量产通用计算、桌面级应用摄像头模组、量产IPC产品树莓派5 强在 CPU 和生态写应用、做服务器都行但没有内置 NPU纯 CPU 跑深度学习模型很吃力。你可以外接 USB 加速棒但多一个设备就多一份不稳定供电和散热都更麻烦。Hi3516CV610 是海思的视觉方案做安防摄像头很强SDK 和工具链更适合有量产经验的团队学生或独立开发者直接上手会比较难受。HD1910 恰好卡在中间有 NPU、有完整的 Linux 生态、GPU 不需要你碰买回来插电就能开始写代码。注意如果你要部署的是大语言模型比如 Qwen2.5-7BHD1910 的内存和算力都撑不住老老实实放服务器。它的定位是端侧小模型推理不是本地大模型平台。2. 环境搭建从零开始把裸板跑起来2.1 串口烧录与首次启动拿到 HD1910 第一件事不是写代码而是先把系统烧进去、确认串口能通。这块板子支持 USB 烧录和 TF 卡烧录两种方式我强烈推荐用 USB 烧录速度稳定且不需要额外准备读卡器。准备工作一根 Micro USB 线要能传输数据的不是充电线、一根 USB 转 TTL 串口线推荐 CP2102 芯片的驱动全平台通用、5V/3A 电源适配器。先别急着上电把板子背面的启动拨码开关拨到“USB烧录”档位按住板上的 Download 按键不放同时接上 USB 线到电脑。电脑上会弹出一个新的 USB 设备Linux 系统下可以用lsusb确认lsusb # 正常会看到类似ID 2207:180a 的Rockchip设备这里多说一句原理HD1910 的 SoC 内置了 MaskROM 引导程序上电时如果检测到 Download 引脚被拉低就会进入烧录模式等待宿主机发数据。所以每次烧录前必须保证按键时序正确——先按 Download再上电或插入 USB顺序反了就只能重新断电再来。接着打开官方烧录工具加载厂商提供的统一固件后缀通常是.img点“烧写”后大概两三分钟就完成了。烧完把拨码拨回正常启动位接上串口线注意 TX 接 RX、RX 接 TX、GND 接 GND电源上电串口终端里应该能看到 U-Boot 打印和内核日志sudo apt install minicom sudo minicom -s # 进入配置串口设备选 /dev/ttyUSB0波特率 115200数据位8停止位1无校验看到内核启动日志以后系统应该会自动进到 Ubuntu 的命令行登录界面默认账号 root密码自己从厂商文档里找。首次进系统第一件事就是扩容根分区出厂镜像的根分区一般只占了一小部分 eMMC 空间df -h # 然后用 parted 或厂商提供的一键扩容脚本扩展分区这一步很多人忽略结果用两天发现磁盘满了。HD1910 的 eMMC 出厂预装了 16GB但根分区默认只分了 2GB剩下的空间是未分配状态不扩容就是个定时炸弹。2.2 开发机交叉编译与板端网络连接HD1910 性能有限直接在板子上编译大型程序会等到怀疑人生。我的习惯是在笔记本上做交叉编译或者直接在板子上编译小体量程序大工程全部交叉编译再传上去。装交叉工具链sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu写 CMake 交叉编译工具链文件toolchain-aarch64.cmakeset(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_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)编出来的可执行文件用scp传到板子上scp ./build/demo root192.168.1.100:/root/开发机到板子的网络打通很关键。HD1910 的千兆网口直连路由器然后开发机 SSH 上去。为了让开发体验接近本地我在 VSCode 里装了 Remote-SSH 插件直接把整个工程作为远程文件夹打开编辑、保存、终端操作都在板子上完成延迟极低。另外条件允许的话我建议配一个 Samba 共享目录把板子的/opt共享到开发机这样编译输出和素材传输能省掉大量 scp 操作sudo apt install samba sudo vi /etc/samba/smb.conf # 添加 [develop] 段path/optwritableyes这套环境搭完之后开发效率会有一个质的提升。前两三天磨刀不误砍柴工后面调试模型和业务代码时就会觉得顺手很多。3. 模型部署实战从YOLOv5到NPU推理3.1 模型转换流水线PyTorch - ONNX - RKNN模型部署是整个项目的核心。我以 YOLOv5s 为例讲完整的转换链路你在自己训练的模型上照搬即可。HD1910 的 NPU 用的是瑞芯微的工具链也就是 RKNN-Toolkit2 那一套所以转换流程是PyTorch训练权重 - ONNX - RKNN格式。首先在 PC 上用官方仓库导出 ONNXpython export.py --weights yolov5s.pt --include onnx --opset 12导出之后强烈建议先用onnxsim做一次简化把 BN 融合、常量折叠这些优化做掉pip install onnxsim python -m onnxsim yolov5s.onnx yolov5s-sim.onnx然后安装 RKNN-Toolkit2PC端工具包写转换脚本from rknn.api import RKNN rknn RKNN() # 重点mean_values 和 std_values 要和训练时的预处理一致 rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk1106 ) rknn.load_onnx(modelyolov5s-sim.onnx) # 量化需要dataset.txt每行一张用于校准的图片路径建议300~500张覆盖真实场景 rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(yolov5s.rknn)这里有几个我踩过的大坑必须强调第一mean_values和std_values不能拍脑袋填。YOLOv5 训练时默认预处理是把像素除以 255所以 mean0、std255 是对的。如果你训练时用了自己的归一化参数转换时不一致模型精度会直接雪崩甚至检测框完全乱飞。第二INT8 量化必须用有代表性的校准图片。我第一版量化随便拿了 50 张网上下的图片做的校准结果模型在真实场景里置信度普遍下降 20%换了 300 张现场拍的照片重新量化后才恢复正常。校准集决定了量化后模型的分布多花点时间整理图片绝对值得。第三RKNN版本要严格匹配PC 端用哪个版本转换出的 rknn 文件板端 runtime 就得上对应版本的 RKNNLite。版本不一致最常见的表现就是初始化失败或者推理结果错乱排查方式后面单独讲。3.2 板端推理Python快速原型和C测帧率HD1910 板端推理最简单的方式是用 RKNNLite 的 Python API。先pip install rknnlite板端安装包从厂商手里拿然后写推理脚本import cv2 import numpy as np from rknnlite.api import RKNNLite rknn_lite RKNNLite() rknn_lite.load_rknn(yolov5s.rknn) rknn_lite.init_runtime() img cv2.imread(test.jpg) # letterbox缩放保持宽高比填充114 scale, offset letterbox(img, (640, 640)) input_tensor img / 255.0 input_tensor input_tensor.transpose(2, 0, 1).astype(np.float32) input_tensor np.expand_dims(input_tensor, axis0) outputs rknn_lite.inference(inputs[input_tensor]) # outputs 的形状一般是 [1, 25200, 85] boxes postprocess(outputs[0])不少人在预处理这步翻车直接把cv2.resize把 1080p 图片压到 640×640没有做 letterbox导致画面被拉伸变形检测框位置全错。YOLOv5 后处理解码时隐含了 letterbox 带来的坐标偏移所以输入侧必须保证同样的缩放方式。letterbox 的填充值用 114这是 YOLOv5 训练时默认的别改改了模型同样会掉精度。推理后处理部分是个体力活本质就是解析 YOLO 输出的[25200, 85]矩阵前 84 维是类别概率最后 1 维是置信度用阈值过滤低分框再用 NMS 去除重复框。这些逻辑直接用 ultralytics 的官方后处理改一版即可我建议一开始别自己重写 NMS先用官方代码跑通再考虑性能优化。确认 Python 版本结果正常后要上 C 测真实帧率。用 C 主要是两个原因一是 Python 的预处理在 CPU 上耗时占比太高二是后续接入摄像头和视频流转发C 比 Python 稳得多。CMake 里关键部分find_package(OpenCV REQUIRED) target_link_libraries(detect rknn_api ${OpenCV_LIBS} pthread)C 端的 RKNN API 和 Python 很接近rknn_init加载模型rknn_inputs_set传输入rknn_run推理rknn_outputs_get取输出。实测下来 Python 端一帧推理前后处理约 45msC 端可以压到 30ms 以内差距主要来自预处理。如果你是做实时视频流务必用 C。3.3 可视化部署训练曲线、推理界面和视频推流模型部署完成之后“可视化”是大多数人忽略但极其关键的环节。不是说模型跑通了就万事大吉你要能看到它跑得怎么样。训练阶段的可视化用 TensorBoard 就够了python train.py tensorboard --logdirruns浏览器打开http://localhost:6006能看到 loss 曲线和 mAP 曲线。这是判断训练是否收敛的最直观方式。推理阶段的可视化我用 Gradio 搭了一个 Web 演示界面手机和电脑都能直接访问非常适合项目汇报和现场测试import gradio as gr def detect_image(img): boxes run_inference(img) draw_img draw_boxes(img, boxes) return draw_img gr.Interface( fndetect_image, inputsgr.Image(typenumpy), outputsgr.Image(typenumpy) ).launch(server_name0.0.0.0, server_port7860)在 HD1910 上跑 Gradio 不会占用太多资源它的作用只是验证模型效果不是生产级服务。另外如果想把摄像头实时画面推到 Web 端看可以直接用 ffmpeg 推 RTSP 流ffmpeg -f v4l2 -i /dev/video0 -c:v h264_omx \ -b:v 2000k -f rtsp -rtsp_transport tcp rtsp://0.0.0.0:8554/live.sdp这里要提醒一下HD1910 跑 ffmpeg 推流时 CPU 占用会明显上升如果同时还跑推理建议把编码分辨率降到 720p否则整体帧率会被拖下来。做边缘 AI 项目资源永远要先保证推理核心任务。经验之谈模型部署阶段的“可视化”解决的是信任问题。老板、客户、合作方看到可视化界面才相信模型真的能工作。项目交付前花一晚上把可视化界面做好比多调几个百分点 mAP 更管用。4. 硬件调试把“跑不起来”变成“稳定跑”4.1 常用调试工具与接线板子跑起来之后硬件调试才是真正拉开新手和老手差距的地方。HD1910 的硬件调试主要围绕四类工具串口、JTAG、逻辑分析仪、万用表。串口是最基础也最常用的调试手段。Linux 下内核崩溃、驱动加载失败、应用异常都能在串口终端里看到 log。比如摄像头初始化失败时串口里通常会有类似mipi csi: failed to probe sensor之类的报错这比对着代码猜要快得多。JTAG 用于低层调试比如裸机程序、U-Boot、内核早期的初始化问题。HD1910 上引出的是标准 ARM JTAG 接口用 J-Link 加 OpenOCD 可以做断点调试和寄存器查看。但说句实话大部分 AI 应用层开发用不到 JTAG除非你在调试 U-Boot 或者自己写的内核驱动。逻辑分析仪是我这次项目里用得最多的工具。调试 MIPI 摄像头时图像一直黑屏我第一反应就是用逻辑分析仪去抓摄像头和控制器的 I2C 通信波形确认 sensor 的 ID 有没有读回来。如果 SCL 有正常时钟但 SDA 没有 ACK说明 sensor 的 I2C 地址不对或者供电没起来。这类问题靠看代码基本无解抓波形一抓一个准。接线有个万年级的坑串口 TX/RX 接反。USB 转 TTL 线标注的 TX 要接板子的 RX线标注的 RX 要接板子的 TXGND 必须共地。接反的典型现象是终端里完全没输出或者输出乱码。另外 USB 转 TTL 线芯片也分两种CP2102 和 CH340 的驱动都能在 Linux 内核里找到如果dmesg | grep tty看不到新设备大概率是线坏了或者驱动没装。4.2 供电、散热、时序与信号完整性问题HD1910 上最常见的一类稳定性问题根源都在供电。官方说支持 5V/3A但我一开始图省事用了一个 5V/2A 的旧充电头结果板子在高负载推理时频繁重启。查串口日志最后只看到干干净净的“suddenly reboot”没有任何异常输出。换 5V/3A 电源后问题立刻消失。这里解释一下原因NPU 满负载运行时瞬间电流可能冲到 2.5A 以上劣质电源电压跌落幅度过大SoC 内部电源监控电路检测到欠压就强行复位。更坑的是劣质 USB 线也有压降线长超过一米且线径细的话就算电源标称 3A到板端实际电压也只剩 4.6V 左右。散热同样不能忽视。HD1910 运行 YOLOv5s 推理二十分钟后SoC 表面温度可以到 70℃ 以上。芯片温度过高时 NPU 会主动降频表现出来的特征就是帧率刚开始正常越跑越慢。我加了散热片加 5V 风扇主动散热后温度稳定在 52℃ 左右推理帧率一路稳定不掉。时序问题在调试外设时经常遇到。HD1910 上接的一些传感器模组要求上电顺序严格先给模组供电再初始化 I2C。如果代码里把初始化跑在模组上电稳定之前模组就会应答一个错误状态。解决办法是在初始化之前加延时或者用单片机 GPIO 控制模组供电时序。HD1910 有 40Pin GPIO完全可以用一个 GPIO 做外设电源开关代码里先拉高 GPIO延时 100ms再去做设备探测。4.3 常见故障排查实录一张实用的速查表做这个项目的三个月里我攒了一份 HD1910 的排障记录整理出来供参考故障现象可能原因排查手段频繁重启供电不足、电源线压降过大、过热换5V/3A电源和短线加散热风扇串口看最后一条日志串口无输出TX/RX接反、波特率错误、驱动未装、线材坏更换串口线确认115200 8N1dmesg看tty设备推理结果全黑或框乱飘预处理归一化不一致、通道顺序RGB/BGR错误检查mean/std/scale值打印输入tensor前几个像素做对比模型加载失败RKNN版本不匹配、模型文件损坏查PC端RKNN版本和板端RKNNLite版本重新导出rknnUSB摄像头无法识别内核缺少UVC驱动dmesg看内核报错重新编译内核模块NPU推理帧率越来越慢过热降频、内存碎片查看温度重启应用观察是否恢复增加内存清理逻辑I2C设备探测不到地址错误、上电时序不对、上拉电阻问题逻辑分析仪抓波形用 i2cdetect -y 扫描地址排查的通用思路是“从物理层到应用层”先确认电有没有供对再确认通信波形对不对再确认驱动有没有加载最后才检查应用代码。很多人一上来就翻应用日志结果浪费大量时间问题其实在电源线。5. 上层软件开发让边缘端真正服务于业务5.1 应用层服务架构推理加MQTT加Web API模型在 HD1910 上稳定推理之后接下来要考虑的是怎么把它变成一个能用的产品而不只是一个“能跑 demo 的板子”。我的做法是搭一套轻量服务架构摄像头采集画面 - NPU 推理得到结构化数据 - 业务逻辑判断 - MQTT 上报到云端 - Web 可视化。数据流向大概是这样的Camera → 推理节点 → 业务过滤 → MQTT发布 → 云端订阅/存储 → Web展示HD1910 上跑 MQTT 客户端用 Python 的 paho-mqtt 库就行import paho.mqtt.client as mqtt client mqtt.Client(hd1910_device_001) client.connect(192.168.1.50, 1883, 60) # 检测到目标时发布事件 client.publish(device/001/detect, payload{type: person, conf: 0.92, ts: 2025-01-01 10:00:00})这里有个设计原则值得强调不要在边缘端上传整张图片或视频流除非网络条件特别好。更合理的做法是上传“检测结果的结构化描述”比如目标类别、置信度、坐标、时间戳。这样即使设备成千上万台云端也只接收文本数据负载极低。只有在需要人工复核的场景才把检测框截图压缩后上传比如 JPEG 质量压到 80一张图也就几十 KB。Web 端展示可以用 Node-RED 或者简单的 Flask 应用订阅 MQTT实时显示检测事件。HD1910 本身可以开发一个轻量 Web API对外暴露推理接口方便其他系统集成from flask import Flask, request, jsonify app Flask(__name__) app.route(/detect, methods[POST]) def detect(): img request.files[image].read() # 调用NPU推理封装 result run_inference(img) return jsonify(result)Flask 在 HD1910 上跑很轻松请求量不大时完全没问题。如果并发要求高建议换 gunicorn 或直接上 C 的 HTTP 框架。5.2 端上检测加云端大模型理解小模型和大模型分工HD1910 跑不了大语言模型但可以作为一个“眼睛”和大脑配合。我正在做的项目就是端侧 YOLOv5 检测到人员/车辆事件后把结构化描述发给云端的大语言模型让大模型生成自然语言的安全告警说明再推送给管理员。这样既保证了端侧实时性又借用了大模型的语义理解能力。云端部署大模型我用的是 Ollama 跑 Qwen2.5-7B官方仓库直接拉模型就能跑无需额外写推理代码ollama pull qwen2.5:7b ollama run qwen2.5:7b也可以用 vLLM 做并发更高的部署生产环境更推荐后者docker 起一个 vllm 服务docker run --gpus all -p 8000:8000 \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5HD1910 这边通过 HTTP 请求调用云端的 OpenAI 兼容接口import requests def generate_report(detect_info): prompt f根据以下检测结果生成一条简洁的安全告警消息{detect_info} resp requests.post( http://192.168.1.100:8000/v1/chat/completions, json{ model: qwen2.5, messages: [{role: user, content: prompt}] }, timeout10 ) return resp.json()[choices][0][message][content]这种“端侧小模型 云端大模型”的组合是目前边缘 AI 项目里很实用的架构。关键要控制调用频率不是每一帧都请求大模型而是检测到特定事件才触发否则云端压力大端侧也会因为等待响应卡死。注意大模型部署到云服务器上模型下载和依赖安装都比较繁琐建议先本地跑通 Ollama 单机方案再迁移到 vLLM 生产方案。另外模型文件的版本要和推理代码保持一致不同量化等级的输出风格差异还挺大的。5.3 边缘AI项目的交付经验稳定性、日志和自动化启动最后讲一点交付层面的事这些经验来自我实际被用户“坑”之后的反思。边缘设备不像服务器有人天天盯着它一旦装到现场就必须自己稳定运行无人值守。第一件事开机自启动用 systemd不要往/etc/rc.local里塞脚本。写一个 service 文件[Unit] DescriptionHD1910 Edge AI Service Afternetwork.target [Service] ExecStart/opt/edge_service/start.sh Restartalways RestartSec5 [Install] WantedBymulti-user.target为什么用 systemd因为Restartalways能保证进程意外退出后自动拉起。服务挂掉几分钟没人管对业务可能就是一笔损失。第二件事日志必须轮转否则设备 storage 会被日志文件撑爆。配置logrotate/opt/edge_service/logs/*.log { daily rotate 7 compress missingok copytruncate }第三件事模型文件和代码版本要绑定记录。我习惯把模型的 md5 和 Git commit hash 一起写进日志的启动头这样现场出问题才能快速定位是什么时候、哪个版本导致的。有次现场模型效果异常所有配置都没动过最后查出来是运维同事远程更新了模型文件没人记录版本排查了两天。从那以后我强制要求所有模型文件名必须带版本号比如yolov5s_v3_int8.rknn而且旧模型不原地覆盖归档到models/archive/目录。第四件事网络掉线重连逻辑必须写。HD1910 现场的 Wi-Fi 信号不可能永远稳定MQTT 客户端要配置自动重连并且断线期间的事件要缓存到本地 SQLite重连后补发。不然网一抖数据就丢了业务侧看到的检测记录有缺口投诉就到你这来了。一些实际操作中形成的个人习惯最后分享几条我在这块板子上沉淀下来的实操习惯算不上方法论但确实帮我省了很多时间。第一新板子到手先不要碰任何 AI 应用先花半天时间做“压力测试”跑一个死循环让 CPU 和 NPU 满载观察温度和稳定性。如果这个阶段就频繁重启说明硬件、电源、散热有问题这时候排查成本最低。等你已经把模型和业务代码都部署上去了再查硬件故障就非常痛苦。第二所有环境变量统一写在/etc/profile.d/hd1910.sh里不要随手在 shell 里 export。现场设备重启后shell 里的 export 全部失效但应用又被 systemd 拉起来了结果应用找不到环境变量路径直接崩溃。这个坑我踩过两次后来把环境变量集中管理后这类问题彻底绝迹。第三模型转换和量化尽量在电脑上批量做不要天天在板子上折腾。我专门写了一个脚本把 PyTorch 权重转 ONNX、ONNX 转 RKNN、格式校验串成一条命令每次训练完一键产出板端模型。省下来的时间够多调两个晚上的参数。第四遇到诡异问题先录日志不要凭感觉猜。HD1910 的串口日志、内核日志、应用日志分别记录排查问题时按时间线对齐看。很多时候问题不在一块板子而是多块板子之间的个体差异没有日志做交叉对比就会一直原地打转。Microduck-HD1910 这块板子整体来说是一块很适合练手的边缘 AI 开发平台它让你能用较低的硬件门槛把“模型部署-硬件调试-软件开发”这条路完整走一遍。走完这条路之后再去看市面上的边缘 AI 产品就会发现它们内部也就是这几件事的组合。希望这篇教程能帮你在自己的项目上少踩几个坑尤其是别在我栽过的地方再栽一次。