设想一个场景你手上有一台宇树Go2四足机器人想让它自己完成目标检测和跟随任务。算法本身不是最大的障碍——YOLOv5训练大家都会真正头疼的是怎么把它部署到Jetson Orin这样的边缘设备上再跟Go2打通通信让整个系统在机器人上稳定跑起来。这篇记录的是我从零到一把YOLOv5目标检测模型边缘部署到Jetson Orin以Orin NX 16GB为例再和宇树Go2做联动控制的完整过程。内容包括硬件选型逻辑、JetPack刷机、自定义数据集训练、PyTorch转ONNX再转TensorRT、ROS2联调以及一路上踩过的各种坑——有些坑网上资料极少我是靠反复实验和日志分析才走出来的。适合三类人看刚接触四足机器人视觉开发的同学、在Jetson上被环境配置和模型转换折磨的开发者、以及正在做边缘部署实时推理的工程师。我尽量不讲虚的给出的命令和代码都是实际跑过的。1. 项目全貌为什么是Go2、YOLOv5和Jetson Orin这个组合1.1 四足机器人边缘部署的算力账先算一笔账。Go2的机载计算单元处理SDK通信、运动控制、状态反馈这些轻量任务没问题但要在上面跑YOLOv5实时推理帧率立刻见底。YOLOv5s在普通CPU上单帧推理可能要几百毫秒加上图像采集、缩放、归一化、NMS前后处理整条链路轻松超过一秒这个速度根本做不了闭环控制。检测任务要实用至少得保证10FPS以上稳定输出理想状态是20~30FPS否则机器人反应永远慢半拍。于是外挂算力成了四足机器人视觉任务的标配做法。在Go2的背部扩展结构上加装一块Jetson Orin模块通过网线或WiFi与机身主控通信。Jetson Orin系列是目前边缘端跑视觉模型最主流的硬件平台之一Orin Nano和Orin NX在算力与功耗上对机器人负载比较平衡。以Orin NX 16GB为例25W功耗下能提供约100 TOPS稀疏算力跑YOLOv5s级别的模型非常轻松。这里有一个选型经验Orin Nano 8GB还是Orin NX 16GB取决于任务复杂度。如果只跑一个目标检测模型Orin Nano 8GB够用如果后面还想接语义分割、姿态估计、多路相机输入直接上Orin NX 16GB免得后期为显存发愁。我自己一开始图便宜用了Orin Nano后来想同时跑检测和深度估计显存直接爆了只能换NX白白多花一笔硬件钱和时间。1.2 部署链路总览从训练到机器人联动的完整路径我的部署链路分两段训练阶段在PC上完成部署阶段在Jetson上完成。完整链路如下PC端准备数据集 → YOLOv5训练 → 得到best.pt权重Jetson端把best.pt导出为ONNX → 用TensorRT构建engineJetson端摄像头采集 → TensorRT推理 → NMS → 输出检测框联动环节检测结果发布到ROS2话题 → Go2控制节点订阅 → 下发运动指令这里必须解释一个关键选择为什么要中途跨一个ONNX因为TensorRT不能直接读取PyTorch的权重格式ONNX是它和PyTorch之间的标准化中间表示。这个步骤看似多余实则是绕开不同框架算子差异的关键。转成ONNX之后你还能用Netron可视化模型结构确认每一层的输出形状是否和预期一致排查问题比盯着PyTorch权重方便得多。1.3 YOLOv5不是最新但一定是边缘部署最稳的选择现在YOLOv8、YOLOv9甚至YOLO11都出来了为什么我最后选了YOLOv5我的判断标准只有一个边缘部署场景里生态成熟度大于算法先进性。YOLOv5的TensorRT部署案例最多ONNX导出基本不用折腾GitHub上能找到大量现成的推理优化项目真出了问题也能搜到前人踩坑记录。对于项目周期紧、要落地到真实机器人的任务这不是情怀是效率。实测下来YOLOv5s在Orin NX上FP16推理已经能跑到50FPS完全够用。如果对精度有更高要求同一套流程换成v5m或v5l也只是改一行配置文件的事。2. 环境搭建阶段JetPack版本选择和刷机那些坑2.1 为什么我坚持用JetPack 5.1.2而不是JetPack 6拿到Orin NX后第一件事是刷机。这里我强烈建议项目初期JetPack 5.1.2对应Ubuntu 20.04是比JetPack 6稳妥得多的选择。为什么JetPack 6虽然新但很多第三方库的兼容性问题还在陆续暴露尤其是YOLOv5往TensorRT转换时旧教程里的命令和方法在JetPack 6上可能直接失效。JetPack 5.x有大量经过验证的部署案例社区遇到过的坑基本都能搜到解决方案这对一个工期紧的项目来说是决定性优势。刷机用英伟达官方SDK Manager操作插上电源用USB数据线连接主机把Orin进入恢复模式软件会自动下载系统镜像并烧录整个过程大概半小时到一小时。刷完以后记得确认一下系统里预装的CUDA、cuDNN、TensorRT版本。JetPack 5.1.2默认自带CUDA 11.4、cuDNN 8.6、TensorRT 8.5这三个版本号后面所有依赖都要对齐。2.2 刷机后黑屏的快速判断顺序刷完机第一次开机黑屏这个现象很多人遇到过而且网上信息特别杂。我总结了一套排查顺序按照这个顺序走基本半小时内能定位问题先换电源。Orin Nano在满载时瞬时电流很高劣质电源或供电不足会导致开机过程中黑屏或反复重启建议用原装适配器别拿普通手机充电器凑合。再换HDMI线和接口。Jetson对显示器握手协议比较挑换一根HDMI 2.0线或者试试Type-C转HDMI很多黑屏问题其实是线材兼容性。最后重刷系统。用SDK Manager重新烧录刷机过程中不要碰USB线不要断电。重刷之后如果还是黑屏那就大概率是硬件供电或主板问题直接走售后更实际。我在这个坑上耗了一整天最后发现是第二根HDMI线的问题。所以如果你也遇到黑屏不要第一时间怀疑系统刷坏了先从最简单的线材开始排查。2.3 CUDA、cuDNN、TensorRT、PyTorch的版本匹配Jetson刷完系统CUDA、cuDNN、TensorRT都预装好了但PyTorch需要自己装。这里最大的坑是版本匹配。Jetson上的PyTorch不能直接从pytorch.org用pip安装必须装NVIDIA提供的JetPack专用预编译轮子。以JetPack 5.1.2为例需要去NVIDIA官方的PyTorch for Jetson页面下载对应版本的whl文件然后pip安装。装完之后一定要做版本验证别急着往下走import torch print(torch.__version__) print(torch.version.cuda) print(torch.backends.cudnn.version()) print(torch.cuda.is_available())如果torch.cuda.is_available()返回False多半是PyTorch版本和系统CUDA不匹配。这时候别想着自己编译PyTorch太耗时了直接换对应版本的官方wheel重新装。我的环境配置建议用miniforge创建独立conda环境不要动系统自带的Python3环境避免把TensorRT的python绑定搞坏PyTorch装1.13或2.0的JetPack专用版本即可没必要追新不要随意升级系统预装的numpy等核心库Jetson上很多组件对numpy版本有隐式依赖升级后可能把TensorRT的接口弄挂3. 模型训练与自定义数据集从标注到能部署的best.pt3.1 数据集的获取与YOLO标注格式我这个项目的视觉任务是安全帽佩戴检测。数据集来源有两种直接用公开数据集网上能找到不少标注好的安全帽数据集或者自己采集现场图片标注。如果是做园区巡检强烈建议自己去现场拍一些照片加进数据集因为公开数据集里没有你实际场景的光线、角度和背景容易训练出实验室很准、现场拉胯的模型。标注工具用LabelImg或者LabelStudio都行。YOLOv5的数据集格式必须严格遵循每张图片对应一个txt文件每行格式是 class_id x_center y_center width height四个坐标值都是归一化到0~1的浮点数。类别编号从0开始比如两类0表示戴了安全帽1表示没戴。数据集目录结构datasets/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── safety_hat.yamlsafety_hat.yaml里写清楚path、train、val路径以及nc类别数和names类别名列表。3.2 yolov5超参数调整的经验训练阶段涉及超参数这个概念YOLOv5在data/hyps/目录下提供了几个默认超参数文件我用的是hyp.scratch-low.yaml。几个关键的调整点输入分辨率imgsz默认640边缘部署建议训练时就用640或416。我最终推理用640训练也用640保持一致性避免部署时resize导致精度损失。batch大小看显卡显存一般8到32之间显存不够就调小并同步降低学习率。epochs一般100到300小数据集建议150左右太少了欠拟合太多了过拟合。小数据集建议关闭mixup增强保留mosaic增强效果更可控。训练命令python train.py --data safety_hat.yaml --weights yolov5s.pt --epochs 150 --batch-size 16 --img 640训练结束后runs/train/exp/weights/下会生成best.pt和last.pt。这里有一个容易被忽略的经验best.pt是按验证集mAP选出来的如果验证集和实际部署场景差异大best.pt不一定真的best。我每次训练完都会用一组现场录制的视频做个目测验证确认泛化效果再进入部署环节。3.3 训练中我踩过的三个坑第一个是路径问题。数据集路径绝对不能有中文YOLOv5读取数据集时对中文路径支持很差轻则警告重则直接报错找不到图片。第二个是类别编号和YAML不一致。有一次我标注时把类别顺序弄反了训练日志显示mAP一直为0排查了很久才发现是标签编号和names对不上。训练前务必检查labels目录里的txt文件第一列数值是否都在0到nc-1范围内。第三个是过拟合。安全帽数据集如果只有几百张图很容易在训练后期val loss不降反升。我当时的处理办法是增加现场采集的难例样本比如背光、遮挡、远距离小目标比调任何超参数都有效。4. 模型转换从PyTorch权重到TensorRT引擎4.1 导出ONNX固定尺寸还是动态尺寸训练出best.pt之后下一步是转成TensorRT能直接加载的engine文件。TensorRT不能直接读取.pt文件所以先用YOLOv5官方仓库自带的export.py导出ONNXpython export.py --weights best.pt --include onnx --img 640这里的关键决策是不要加--dynamic。动态输入尺寸虽然灵活但TensorRT在动态shape下会保留更多运行时分支无法做极致的层融合优化推理速度会打折扣。我在部署时确定了输入就是640×640所以导出固定尺寸的ONNX让TensorRT把网络结构优化到最佳状态。导出完成后用Netron打开onnx文件确认输入输出节点。YOLOv5的原始输出是一个三维张量以COCO 80类为例是1×25200×8525200是三个尺度特征图上的anchor总数80×8040×4020×20×385是4个框坐标加1个置信度加80个类别得分。如果是2类安全帽检测输出就是1×25200×7。这个输出还需要经过解码和NMS最终才能得到检测框。4.2 trtexec构建TensorRT引擎FP16和INT8怎么选Jetson上自带trtexec命令行工具构建引擎的命令/usr/src/tensorrt/bin/trtexec \ --onnxbest.onnx \ --saveEnginebest.engine \ --fp16 \ --workspace2048--fp16开启半精度推理在Orin NX上相比FP32速度大约能翻倍精度损失很小是边缘部署的默认选项。--workspace是构建阶段允许使用的显存上限设大一点能容纳更多优化方案实际推理时只占用最终引擎的大小不用担心。如果FP16的精度还不满足需求可以进一步尝试INT8量化。INT8需要额外的校准过程让TensorRT统计模型各层激活值的分布从而确定量化截断阈值。命令大致是/usr/src/tensorrt/bin/trtexec \ --onnxbest.onnx \ --saveEnginebest_int8.engine \ --int8 \ --calibcalibration_data我的实测结论安全帽检测这种大目标任务INT8精度损失很不明显但推理速度还能再提升30%到40%。如果你做的是小目标检测或者像素级精细任务INT8要谨慎先用FP16跑通流程再决定要不要上量化。4.3 构建引擎失败的排查思路构建过程中最常见的报错是unsupported operator算子不支持。遇到这类问题我的排查顺序是先确认ONNX版本、PyTorch版本和TensorRT版本的兼容性这是最大的概率来源。调整导出ONNX时的opset版本YOLOv5 export.py默认opset可能是12改成11往往能绕过一些兼容性问题。在导出命令里加上--simplify用onnx-simplifier对计算图做简化很多冗余节点会被合并或删除。有一个容易被忽略的细节构建引擎时不要手动关掉终端。trtexec在构建比较大的模型时会持续几分钟中间看似卡住实际上在跑优化我一度以为程序挂了连着几次手动中断后来才发现应该耐心等它输出完毕。4.4 推理代码框架与前后处理开销引擎构建好之后我用TensorRT的Python API写推理脚本。核心流程是加载engine → 创建context → 分配输入输出缓冲区 → 执行推理。伪代码如下import numpy as np import tensorrt as trt def load_engine(engine_path): logger trt.Logger(trt.Logger.WARNING) with open(engine_path, rb) as f, trt.Runtime(logger) as runtime: return runtime.deserialize_cuda_engine(f.read()) engine load_engine(best.engine) context engine.create_execution_context() # 分配输入输出缓冲区 input_buf np.empty((1, 3, 640, 640), dtypenp.float32) output_buf np.empty((1, 25200, 7), dtypenp.float32)实际使用时输入帧要经过resize到640×640、BGR转RGB、归一化到0~1输出要经过解码框坐标、置信度阈值过滤、NMS去掉重叠框。这里有一个容易忽视的点NMS放CPU还是GPU。我的方案里NMS是用NumPy在CPU上做的640×640输入、单张图NMS约耗时2到3毫秒影响不大。如果对延迟极度敏感可以把预处理和NMS都扔到GPU上但工程复杂度会高不少建议先把简单方案跑通再优化。5. 与宇树Go2的联调ROS2通信与检测结果闭环5.1 在Jetson上搭建go2开发环境联调阶段我选了ROS2作为通信中间件。宇树社区有官方ROS2功能包支持Foxy和Humble两个版本。JetPack 5.1.2对应Ubuntu 20.04所以装ROS2 Foxy。sudo apt install ros-foxy-desktop安装完成后拉取宇树官方的unitree_ros2仓库按README用colcon编译。编译过程中需要装一些依赖包遇到缺什么就apt装什么。这里有一个实战提醒如果你同时装了ROS1和ROS2环境变量容易互相干扰每次打开新终端时确认source的是Foxy的setup.bash不然会发现话题名对不上或者命令找不到。Go2的通信原理是机器人机身通过局域网暴露SDK接口你下发运动指令实际上是通过UDP协议和它通信。ROS2功能包把这些封装成了话题和服务你不需要关心底层报文格式。5.2 检测节点与控制节点的数据通路设计我的节点设计分为三个camera_node采集USB摄像头图像发布到sensor_msgs/Image话题yolo_node订阅图像话题执行TensorRT推理发布自定义检测结果话题go2_ctrl_node订阅检测结果调用Unitree SDK发送运动指令自定义消息我定义了一个DetectionArray包含每个目标框的x、y、w、h、class_id和confidence。你也可以直接用ROS2标准库里的vision_msgs/Detection2DArray省去自己编译自定义消息的步骤。我用自定义消息是因为字段更直接改起来方便。节点之间通过话题解耦好处是任何一环出了问题其他节点还能独立运行。实际调试时我可以只启动camera_node和yolo_node用ros2 topic echo查看检测结果不连机器人本体就能验证视觉算法等一切稳定再启动go2_ctrl_node。5.3 检测结果如何驱动Go2动作拿安全帽检测做例子当yolo_node检测到画面中有未戴安全帽的人go2_ctrl_node收到结果后控制Go2停下来并发声提示。运动控制指令通过Unitree SDK封装好的接口下发你只需要关心目标速度、转向角这些高层指令。实现逻辑可以写成这样目标在画面左侧Go2左转目标在画面右侧Go2右转目标在画面中央且距离较近Go2减速或停止没有检测到目标Go2匀速前进这个方案做缓慢跟随和定点巡检完全够用。这里要强调一点不要试图在应用层直接去调Go2的关节电机。宇树SDK已经把运动控制封装得很成熟电机层面的调试和标定是另一套体系和视觉部署是两个层面的事混在一起只会让项目失控。5.4 实际联调时最影响体验的几个问题联调阶段最大的问题是整体延迟。Jetson推理本身只要20到30毫秒但加上图像采集、话题传输、SDK指令下发整个闭环延迟会到100毫秒以上。对这个延迟要有心理预期机器人做缓慢跟随可以做快速避让不够。另外一个坑是双机通信。如果你让Jetson和开发电脑同时连Go2所在局域网ROS2的DDS自动发现机制默认会跨设备广播节点之间会发现私聊但偶尔也会出现两边话题对不上的情况。解决办法是配置统一的ROS_DOMAIN_ID或者在每台设备上设置相同的rmw实现避免两边用的DDS类型不一致。6. 踩坑排查链路三个让我熬夜超过一天的问题6.1 推理脚本报错CUDA error: out of memory但不是显存不够这是我在联调阶段卡得最久的一个问题。现象是单独跑yolo_node没事把camera_node、yolo_node、go2_ctrl_node一起启动后跑几分钟就报CUDA out of memory。一开始我以为是显存不足把模型从YOLOv5m换成了YOLOv5s显存占用降下来了但问题依旧。排查链路是这样的用nvidia-smi监控显存发现推理前后显存占用基本稳定并没有持续上涨排除显存泄漏。怀疑是PyTorch和TensorRT的CUDA context冲突两个框架同时持有显存某个时刻申请不到。于是把PyTorch的推理彻底移除只跑TensorRT问题频率下降但仍有。最后看了系统日志发现是rmw_fastrtps在DDS发现阶段创建了过多临时线程每个线程都干了一小块CUDA显存。解决办法是设置DDS的发现超时时间并限制参与发现的端口范围。最终修复很简单在启动ROS2节点时加上配置参数禁止DDS在同一个进程中初始化大量临时上下文。这个问题告诉我边缘设备上显存是稀缺资源任何依赖CUDA的组件共存时都要留意相互抢占。6.2 TensorRT engine在Go2机载震动环境下偶发推理结果异常这个坑特别隐蔽。现象是办公室桌面测试一切正常把Jetson装到Go2背板上走几圈之后推理结果偶尔出现大量错检过一阵又自己恢复。排查过程很痛苦。我的排查链路先怀疑模型本身的问题把现场录到的错检帧存下来回放后单独推理发现结果恢复正常。说明不是模型鲁棒性问题。怀疑图像传输丢帧检查camera_node到yolo_node的话题帧率发现偶发丢帧但比例很低不影响最终检出排除。最后用jetson_clocks查看芯片状态发现Go2行走时电源电压有波动导致GPU频率被动态拉低推理时间延长图像队列积压后出现了时间戳错乱。解决手段包括给Jetson单独用电感滤波的稳压模块从Go2电池取电在yolo_node里给订阅图像加上时间戳校验丢弃超过500毫秒的旧帧把GPU频率模式锁定在固定档位避免频繁动态调频。从那之后这个问题再也没出现过。6.3 ROS2节点在重启后偶尔互相发现不了这个问题在双机联调时很常见。现象Jetson上的yolo_node和另一台设备上的控制节点第一次启动能正常通信一旦重启其中一台就出现订阅方收不到话题的情况。排查链路用ros2 node list在两端分别查看节点发现两边都能看到自己的节点但看不到对方的说明DDS发现失败。查看防火墙设置发现新装的一些组件把UDP多播端口挡了。ROS2 DDS默认使用多播做节点发现防火墙阻挡后两台设备就失联了。关闭防火墙或者放行端口后重启所有节点通信恢复。如果你也碰到这个问题先别怀疑代码逻辑直接ping通IP后检查防火墙。再不行就在环境变量里设置ROS_DOMAIN_ID确保两端使用同一个domain排除不同域互相隔离的因素。7. 实测数据与调优边缘部署不是能跑就行7.1 Jetson Orin NX上的推理性能实测我的实测环境Jetson Orin NX 16GBJetPack 5.1.2TensorRT 8.5输入640×640。数据如下模型精度模式平均推理耗时估算帧率显存占用YOLOv5sFP16约18ms约55FPS约1.2GBYOLOv5mFP16约32ms约31FPS约2.0GBYOLOv5sINT8约12ms约83FPS约0.8GB注意这些是纯推理耗时不含图像采集和前后处理。整条链路实际帧率大概要打六到七折因为摄像头采集、DDS传输、画框显示都会占用时间。对Go2的跟随任务来说YOLOv5s FP16模式已经满足需求我最后就保持在FP16模式没有上INT8。7.2 整机功耗与散热的取舍Orin NX在性能模式下功耗可以到25W加上相机和Go2自身功耗整机续航下降明显。我实测Go2加挂Orin NX后整机续航大约缩短了20%。如果只是做演示建议把Jetson调到15W电源模式推理帧率依然能保持20FPS以上但发热和续航压力都小很多。散热这块不能省。Orin NX满载时被动散热片在夏天会烫手我后来加了一个5V小风扇直接贴在散热片上温度从75度降到65度左右系统稳定性明显提升。物理安装上Jetson模块要固定牢固Go2行走时震动不小所有排线都用扎带固定避免接口松动。7.3 进一步的性能优化方向如果想把性能再压一截我验证过几个有效手段把输入尺寸从640降到480或416。安全帽检测这类大目标任务精度损失很小推理时间能缩短到10~15ms。使用双缓冲流水线采集线程不停往队列放帧推理线程从队列取帧让采集和推理重叠执行整体吞吐提升大约15%到20%。开启TensorRT的CUDA Graph减少kernel启动开销在Orin上能再省2到3毫秒。摄像头直接用Jetson CSI口走GStreamer管道比USB摄像头少一次USB传输的延迟。7.4 稳定运行的小技巧我最后整理几条让系统长期稳定的经验。第一条给Jetson设置定时重启或看门狗边缘设备长期运行难免出现内存碎片和驱动异常有看门狗能避免项目演示时当场掉链子。第二条所有节点加上日志落盘运行时把关键状态写到文件排查问题不用靠猜。第三条先跑通一个最小闭环再扩展我最早就是先让yolo_node把检测框打印在终端里确认推理链路正常再开始接Go2的运动控制。项目跑通那天我让Go2沿着园区楼道走了一圈它成功识别出经过的施工人员是否戴了安全帽检测到异常就停下来原地提示。说实话YOLOv5和TensorRT都不是新东西这个项目最难的不是某个具体算法而是把一堆版本号、驱动、协议、硬件约束拼在一起让整个系统在真实场景里稳定跑起来。这篇记录里的每一个坑都是真实熬出来的有些问题网上根本搜不到标准答案只能靠日志、变量和耐心慢慢定位。如果你也卡在某个环节不妨按我给的排查顺序走一遍至少能少熬几个夜。边缘部署没有银弹但踩坑的路是可以复用的。