1. 项目概述与整体方案选型1.1 核心需求解析最近手里有个活儿要给宇树Go2四足机器人做一套基于视觉的目标识别能力核心任务是在机载边缘设备上实时跑YOLOv5识别前方障碍物和指定目标物。一开始我犹豫过方案是用Go2自带的算力模组还是外挂一台高性能边缘计算设备。后来综合对比下来选了 Jetson Orin 系列作为外挂算力平台。原因很直接Go2本体虽然有算力模组但要同时跑运动控制、导航SDK和视觉推理资源会很紧张外挂一台Orin图像推理走独立链路机身控制照旧走宇树官方SDK两边互不干扰开发调试也清爽得多。这个项目涉及的环节比较长从硬件选型、JetPack系统烧录、Python/CUDA环境配置、YOLOv5代码拉取与依赖安装到模型训练、权重转换、TensorRT加速再到接Go2的SDK做数据流打通每一环都有坑。我算是把这些坑基本都趟了一遍写出来给后面做同类项目的朋友省点时间。1.2 为什么选 Jetson Orin 而非其他平台边缘部署这事可选平台其实不少树莓派5、Jetson Nano、Jetson Orin NX / AGX Orin、Intel NUC配神经网络加速棒甚至直接上RK3588之类的国产板子。我做选型时主要卡了三个硬指标算力要能跑得动YOLOv5s以上的模型而且不能只是勉强能跑最好留出余量做后续模型升级。视频输入链路要友好毕竟Go2自带的相机是USB输出需要平台对USB摄像头和GStreamer管道有完善的驱动支持。功耗和体积要适合装到Go2机身载板上不能背个巨型供电模块。树莓派5性价比不错但算力用在YOLOv5s上跑到实时30FPS以上很吃力实测大概只能跑到10~15FPS而且TensorRT这种加速生态在树莓派上基本用不了。Jetson Nano属于上一代产品显存和算力都偏低。Orin系列里面Orin NX 8GB/16GB和AGX Orin都很有竞争力最后我选了Orin NX 16GB版本——功耗在10W~25W可调峰值算力能到100 TOPS板子尺寸比一张名片大不了多少非常适合做机器人机载算力。1.3 整体技术链路设计整套系统的架构我画在脑子里是这样的Go2机身上的USB摄像头 → Jetson Orin的USB口 → GStreamer取流 → Python程序逐帧处理 → YOLOv5推理 → 识别结果类别、坐标、置信度 → 通过UDP串口或网络协议回传给Go2的运控SDK → 机器人根据识别结果执行动作。在这个链路里YOLOv5只是中间一环但它决定了整个系统的感知能力上限。所以模型训练和转换环节花的时间最多也是后面踩坑最密集的区域。整个项目跑通之后单帧延迟从最初的120ms以上优化到了35ms左右基本满足Go2室外巡检任务的需求。2. 环境搭建与系统烧录实战2.1 JetPack系统刷机与启动黑屏排查Jetson Orin装系统常规路径是先用另一台Ubuntu主机下载NVIDIA SDK Manager或使用命令行工具烧录JetPack。我这边用的是SDK Manager图形界面烧录的是JetPack 5.1.2自带CUDA 11.4、cuDNN 8.6、TensorRT 8.5这套版本组合在后续装PyTorch和YOLOv5时比较省心。刷机本身没什么技术含量按向导操作就行。真正的坑出现在第一次开机——这也是热搜词里“jetson orin nano启动后黑屏”出现频率很高的原因。我遇到的情况是供电用的是一块12V 5A的DC电源理论上足够但开机后HDMI输出没有画面风扇转一下停一下像是进入了反复重启的死循环。排查了一下午最后发现是供电接触不良和系统引导分区的问题。先说供电Orin NX载板的电源接口看着是标准的DC圆头但不同载板对电源规格要求差异挺大我手里这块载板要求12V 5A换了一根粗线径的电源线后稳定多了。再说系统引导我重新烧录时选择了完整擦除Full Flash而不是仅更新分区Update彻底清空后再烧黑屏问题就消失了。如果你们也遇到启动黑屏优先检查电源线径和载板供电规格其次再考虑重新刷机。2.2 Python与CUDA环境的“最佳实践”配置Orin刷完系统后系统自带的是Python 3.8但NVIDIA的很多工具链依赖特定的Python小版本建议直接用系统Python不要手动升级到3.10/3.11否则后面编译一些依赖包会非常痛苦。我的环境配置顺序是这样的# 1. 更新系统 sudo apt update sudo apt upgrade -y # 2. 安装基础依赖 sudo apt install -y python3-pip libopenblas-dev libopenmpi-dev # 3. 安装PyTorch关键必须用NVIDIA预编译的wheel不能直接用pip install torch # 到NVIDIA官网下载对应JetPack 5.1.2的torch 2.0.0 wheel pip3 install torch-2.0.0-cp38-cp38-linux_aarch64.whl # 4. 安装对应版本的torchvision同样用NVIDIA预编译版 pip3 install torchvision-0.15.0-cp38-cp38-linux_aarch64.whl # 5. 验证CUDA可用 python3 -c import torch; print(torch.cuda.is_available())这里必须强调绝对不能直接从PyPI源pip install torch因为那边默认拉取的是x86_64架构的包在ARM64的Orin上要么报错要么装上一个纯CPU版本GPU完全用不上。NVIDIA为Jetson平台维护了一套预编译的PyTorch wheel包只能在NVIDIA官网的论坛或官方文档里找到下载入口。2.3 YOLOv5代码拉取与依赖安装YOLOv5的官方代码仓库在GitHub上直接git clone就好。但要留意一件事YOLOv5的master分支更新很频繁依赖版本也跟着变如果直接用最新代码很容易出现某个依赖包版本不兼容的问题。我的做法是固定到一个稳定release版本。git clone https://github.com/ultralytics/yolov5 cd yolov5 git checkout v7.0.0 pip3 install -r requirements.txtrequirements.txt里列的依赖比较多其中容易出问题的几个是opencv-python、matplotlib、numpy。在Jetson平台上opencv不建议从pip安装因为NVIDIA的系统里已经预装了一版带CUDA加速的OpenCV直接用系统的版本反而性能更好。如果pip把系统的OpenCV覆盖了后续用GStreamer取流时可能会遇到一堆莫名其妙的报错。我的做法是先装YOLOv5的其他依赖然后手动卸载pip安装的opencv-python-headless保留系统自带的OpenCV。# 安装YOLOv5依赖但不装opencv相关 sed -i /^opencv/d requirements.txt pip3 install -r requirements.txt # 验证系统OpenCV python3 -c import cv2; print(cv2.__version__)这一步能省下后面大量排错时间尤其是当你需要同时用cv2.VideoCapture和GStreamer管道时系统自带OpenCV的兼容性好得多。3. 模型训练、超参数调节与权重转换3.1 训练自己的数据集从标注到格式整理YOLOv5的模型训练是整个项目里最花时间的一环。如果你只是用官方预训练权重做一次验证那很简单但实际项目里几乎都要微调自己的数据集。我在这个项目里用了一个安全帽佩戴检测的数据集后来也扩展了部分自定义目标类别。数据集准备有几个关键点图片数量每个类别至少准备200~500张图片类别越少需要的图片相对越少但背景尽量丰富避免模型过拟合。标注格式YOLOv5使用txt格式的标注文件每行格式是“class x_center y_center width height”坐标值都是归一化到0~1之间的浮点数。数据集目录结构要严格按照YOLOv5的要求排列datasets/ custom/ images/ train/ val/ labels/ train/ val/我踩过的一个坑是用LabelImg标注完导出的格式是Pascal VOC的XML格式需要先转换成YOLO格式。很多新手直接用某个转换脚本一跑了之结果类别编号对不上训练时loss爆表或者干脆不收敛。我的建议是转换完成后抽几张图用YOLOv5自带的验证脚本可视化一下标注框确认框位置正确再开始训练。3.2 YOLOv5超参数的本质理解与调整策略说到超参数很多人直接套用官方默认的hyp.scratch-low.yaml但实际项目里还是要根据自己的数据集和场景做调整。YOLOv5的超参数主要分成几类优化器参数lr0、momentum、weight_decay、数据增强参数hsv_h、hsv_s、hsv_v、degrees、translate、scale、shear、perspective、flipud、fliplr、损失函数权重box、cls、cls_pw、obj、obj_pw等。这里我举几个实际调过的参数lr0初始学习率默认0.01小数据集、类别少的场景可以降到0.005避免前期震荡太厉害。mosaic马赛克增强默认是1.0也就是每张训练图都由4张图拼接。这个增强对小目标检测非常有效但在某些特定场景比如检测目标本身很小、背景单一反而会引入太多噪声可以降到0.5试试。degrees旋转增强安全帽检测场景里帽子在图像中的旋转角度不会太大设成5~10就够了设太大反而让模型学到不真实的姿态。fliplr水平翻转默认0.5这个一般不用改几乎所有目标检测任务都受益于水平翻转。超参数调整不要贪多一次只调一两个观察验证集的mAP变化。我通常是先跑5~10个epoch看趋势再决定要不要继续调。3.3 训练命令与TensorRT导出实战模型结构我选了YOLOv5s输入分辨率640x640在Orin NX上这个分辨率的性价比最高。训练命令python3 train.py \ --data custom.yaml \ --weights yolov5s.pt \ --img 640 \ --batch-size 16 \ --epochs 100 \ --hyp hyp.scratch-low.yaml \ --device 0batch-size在Orin上可以稍微大胆一点16GB显存跑YOLOv5sbatch-size 32也没问题但建议还是16起步先看显存占用再加。训练完成后模型导出TensorRT engine是这个项目提速的关键一步。YOLOv5官方代码自带export.py可以直接导出engine格式但用起来有几个坑。python3 export.py \ --weights runs/train/exp/weights/best.pt \ --include engine \ --device 0 \ --half这行命令会自动调用TensorRT的Python API完成模型转换。但实际执行时经常报错比如“TensorRT: export failure: cant parse the ONNX file”。这个问题的根源是PyTorch导出的ONNX模型里有一些TensorRT不兼容的算子常见的是Focus层——YOLOv5 v6.0之前的版本用Focus做下采样v6.0之后改成了普通的Conv层但老权重转换时还是会遇到。解决方法是升级到v7.0以上的YOLOv5代码或者在导出时把opset版本调高一些python3 export.py \ --weights runs/train/exp/weights/best.pt \ --include engine \ --device 0 \ --half \ --opset 17我用的是v7.0 opset 17的组合一次就过了。导出成功后在推理脚本里直接用torch.hub加载engine文件就能享受到TensorRT加速。4. 与宇树Go2通信串联与实时推理优化4.1 宇树Go2的SDK接入方式回顾宇树Go2提供了丰富的SDK接口常用的有UDP控制接口和网络API。在边缘部署场景下我采用的方案是Jetson Orin作为独立的感知节点推理结果通过UDP协议发给Go2的运控模块。Go2的SDK里有一个UnitreeGo2的Python库可以接收外部指令并控制机器人运动。具体的数据流设计是这样的Jetson Orin端摄像头取流 → YOLOv5推理 → 得到目标类别和坐标 → 计算出目标相对机器人的偏移角度和距离 → 打包成JSON或二进制格式 → 通过UDP发送到Go2的IP地址和端口。Go2端SDK监听UDP端口 → 解析指令 → 控制云台或底盘运动让目标保持在机器人视野中央。这个方案的好处是宇树Go2原有的运动规划能力不需要大改我们只是给它加了一个“视觉大脑”。而且UDP通信的调试成本低两边用Python就能快速联调。4.2 相机取流与GStreamer管道配置Go2机身上的摄像头一般通过USB接到Orin上直接用OpenCV的cv2.VideoCapture(0)就能读取但这种方式在需要高性能时会受限。为了提高实时性我改用GStreamer管道取流配合Orin的硬件编解码单元能显著降低CPU占用。gst-launch-1.0 v4l2src device/dev/video0 ! \ video/x-raw, width1280, height720, framerate30/1 ! \ videoconvert ! \ video/x-raw, formatBGR ! \ appsink在代码里用OpenCV调用GStreamer管道的方式import cv2 pipeline ( v4l2src device/dev/video0 ! video/x-raw, width1280, height720, framerate30/1 ! videoconvert ! video/x-raw, formatBGR ! appsink ) cap cv2.VideoCapture(pipeline, cv2.CAP_GSTREAMER)这里有个细节Go2的相机如果直接插在Orin上设备节点可能是video0也可能是video1取决于有没有其他USB摄像头。建议先用ls /dev/video*确认设备号再调整管道参数。4.3 推理性能优化从120ms到35ms的调优路径YOLOv5在Orin上跑起来后第一版性能其实不理想。我用的是直接加载PyTorch权重的方式推理单帧延迟在120ms左右大概8FPS这对机器人实时控制来说太慢了。优化路径主要做了三步第一步是TensorRT引擎替换。把PyTorch权重换成engine格式后推理延迟直接降到了60ms左右约16FPS。这步收益最大基本是白捡的加速。第二步是输入分辨率调整。从1280x720直接缩放成640x640并调整了摄像头取流分辨率到1280x720推理分辨率保持640x640不变。这一步看似没变实际上是把图像缩放过程从Python的OpenCV操作挪到了TensorRT的预处理阶段省掉了部分拷贝开销。第三步是启用FP16半精度推理。Jetson Orin的Tensor Core对FP16有专门加速启用后延迟压到了35ms左右大约28FPS。如果再激进一点用INT8量化能到20ms以内但INT8量化需要校准数据集而且精度会有轻微下降我没有在安全帽识别这种对精度要求较高的场景使用。优化后的代码骨架大致是import cv2 import torch # 加载TensorRT engine model torch.hub.load(ultralytics/yolov5, custom, pathbest.engine, devicecuda:0) # 视频取流 cap cv2.VideoCapture(pipeline, cv2.CAP_GSTREAMER) while True: ret, frame cap.read() if not ret: continue # 推理 results model(frame, size640) # 解析结果 detections results.xyxy[0].cpu().numpy() for det in detections: x1, y1, x2, y2, conf, cls det label model.names[int(cls)] # 计算目标中心和偏移 cx (x1 x2) / 2 cy (y1 y2) / 2 # 这里把cx, cy和置信度打包发送给Go2有一点要提醒torch.hub第一次加载模型时会联网下载一些配置文件如果运行环境是离线的需要提前把依赖文件准备好。我在调试时遇到过联网超时导致加载失败的情况后来直接把YOLOv5仓库放在本地用custom路径加载彻底断网也能跑。5. 实战踩坑实录与性能调优全记录5.1 启动黑屏与SSH远程排查技巧回到前面提到的“Jetson Orin启动后黑屏”问题我再多说几句。黑屏不等于系统挂了很多时候系统其实正常启动了只是显示输出没有工作。遇到这种情况最有效的办法是直接用网线连接Orin和笔记本通过SSH登录排查。# 在笔记本上扫描Orin的IP地址 nmap -sn 192.168.1.0/24 # 或者直接在路由器后台找新接入的设备 ssh usernameorin-ip登录系统后先看系统日志dmesg | grep -i error journalctl -xe我当时就是从日志里发现显卡驱动初始化失败然后又定位到是电源供电不稳导致GPU降频重启。更换电源后再用sudo systemctl restart gdm3重启图形界面就正常了。5.2 YOLOv5训练与推理中的典型报错整个项目过程中我记录了几类高频错误这里整理成速查表错误现象根因解决方案ModuleNotFoundError: No module named torchvision环境变量或pip安装路径不对确认用pip3而不是pip检查sys.pathCUDA out of memorybatch-size设置过大减小batch-size或启用梯度累积训练loss不为0但mAP始终为0数据集标注类别编号错乱可视化标签检查类别索引与names配置TensorRT export failureONNX算子不兼容升级到v7.0设置--opset 17推理时检测框偏移严重输入图像缩放方式与训练时不一致确保推理时letterbox填充一致use YOLOv5自带预处理GStreamer管道报设备忙碌摄像头被其他进程占用关闭OpenCV的默认videocapture用fuser查看占用进程这里重点说一下“推理时检测框偏移严重”这个问题。YOLOv5在训练时会把图像统一缩放到640x640缩放方式不是简单拉伸而是保持宽高比后用灰色填充剩余区域即letterbox操作。如果推理时直接用cv2.resize把图像拉成640x640检测框的位置和大小就会偏移。所以推理端必须要复用YOLOv5自带的letterbox预处理逻辑我用的是model(frame, size640)这行自动处理不会踩坑。5.3 通信延迟与实时性冲突的折中方案Go2的运控指令要求频率一般在50Hz以上而YOLOv5的推理帧率在28FPS左右这之间天然存在节奏差异。我的做法是视觉推理线程跑独立循环推理结果不断刷新到一个共享变量里发送线程按25Hz的频率把最新结果打包发给Go2即使视觉某帧延迟发送线程依然保持稳定节奏不会让Go2的运控因为收包不均匀而抖动。实际测试下来端到端延迟从画面出现目标到Go2执行动作大约在80ms左右对于巡检、跟随这类任务完全够用。如果你做的是高速动态抓取这类要求极低延迟的任务那就需要把模型换成更轻量的版本或者用INT8量化甚至可以裁剪摄像头ROI只推理画面中间区域牺牲一点视野换速度。5.4 散热与功耗管理的现实考量Jetson Orin NX的性能让人满意但满载时的发热和功耗必须认真对待。我一开始用的是一个不带风扇的被动散热外壳测试时发现长时间跑推理后芯片温度飙到85度然后系统自动降频帧率从28FPS掉到18FPS非常影响体验。后来换成主动散热方案一个5V的PWM风扇对着散热鳍片吹加上一个简单的温控脚本当温度超过70度时提高风扇转速。功耗方面Orin NX我设置了20W的功耗模式sudo nvpmodel -m 0 # 0表示MAXN模式25W1表示15W模式2表示10W模式室外巡检场景我建议用20W模式兼顾性能和续航。如果Go2本身的电池供电能力有限可以考虑用一块独立的USB-PD电池给Orin供电避免大电流负载影响Go2主控的稳定性。6. 方案复盘与后续可扩展方向6.1 目前的实际检测效果整个项目跑通后我做了几轮场景测试。在普通室内光照条件下YOLOv5s模型对安全帽目标的mAP0.5达到了0.93左右推理帧率稳定在28FPS漏检率在可接受范围内。室外强光环境下相机的自动曝光会对检测效果产生一定影响主要表现为逆光时目标偏暗、置信度下降这时可以适当调低置信度阈值从默认的0.25调整到0.2或开启相机的HDR模式。从部署成本角度看整个方案单套硬件成本主要是Orin NX模组和载板的费用软件成本基本为零核心组件都是开源或官方SDK。对比原来租用云端GPU做推理的方案边缘部署的长期成本明显更低而且完全摆脱了网络带宽和延迟的束缚。6.2 可改进的空间在哪里虽然项目已经达到预期目标但我自己也清楚还有几个可改进的方向。第一个方向是模型轻量化。YOLOv5s在Orin NX上跑到28FPS如果换成YOLOv5n或YOLOv8n理论上可以突破45FPS但精度会下降2~4个百分点。对于纯避障任务可以牺牲精度换速度对于识别任务还是YOLOv5s更稳妥。第二个方向是融合深度信息。当前方案只有2D检测框缺少目标距离信息。后续如果接入深度相机如RealSense D435把深度图的对应像素点与检测框中心对齐就能输出目标的3D坐标Go2的机械臂或者底盘避障就更精确了。第三个方向是多传感器融合。Go2本身就带激光雷达和多个视觉传感器如果把YOLOv5的2D检测结果与激光雷达的3D点云做融合再接入宇树SDK的地图模块整个系统的环境感知能力会上一个大台阶。这是后续想花时间深入的方向。6.3 对同样在做边缘部署的人说几句最后分享一点个人的小经验。做边缘部署项目最忌讳的就是“重算法、轻工程”很多人把精力都花在调模型精度上忽略了环境搭建、推理加速、通信链路这些工程环节。实际上在Jetson这类边缘平台上成熟的模型算法反而不是稀缺资源真正决定项目成败的是能不能把模型稳定、高效地跑起来并让它融入整个机器人系统。我在调试过程中最大的体会就是排错一定要有方法论。遇到报错别慌先看日志再复现最小场景最后才动代码。很多时候一个看似复杂的问题根因只是某个依赖包版本不对或者某个USB设备的权限没配好。把基础环境弄扎实后续的迭代速度会快很多。如果这篇文章对正在做宇树Go2开发、Jetson部署或YOLOv5边缘推理的朋友有一点帮助那就值得了。这套流程里的每一个环节都可以单独拿出来深入优化踩坑的路才刚刚开始。
