说实话这套组合第一次摆上台面的时候我心里第一反应是“能跑但肯定有不少幺蛾子”。宇树GO2作为一个四足机器人平台本身主控不算弱但真要端到端跑实时目标检测、做感知联动光靠内置算力还是挺吃紧的。外挂一块Jetson Orin把YOLOv5这类模型部署上去几乎是当前做具身智能原型最主流的方案。但这套链路远没有PPT上那么顺滑。JetPack和PyTorch的版本暗坑、TensorRT导出时的算子兼容问题、GO2图像流接入的格式转换、以及Orin功耗模式没调对导致的随机卡顿任何一个环节都能让你折腾一个周末。这篇文章就把我从零开始在一台Jetson AGX Orin上把YOLOv5接到宇树GO2的完整过程和踩坑记录整理出来尤其是那些报错信息不直观、但确实非常常见的坑。1. 方案总体设计与硬件接线1.1 先说说我搭这套系统的初衷做四足机器人感知最朴素的需求就是机器人在场地里走它能认出前面是什么物体然后我根据识别结果决定是追过去还是绕开。这个需求放到GO2身上有两种实现路径一种是在GO2的主体程序里直接拉通视觉和运动控制另一种是把视觉部分放到外挂算力平台上通过通信协议把识别结果回传给GO2主控。我选了第二种。原因很简单宇树GO2的主控主要精力要花在关节控制、步态算法和SLAM上我不太想让它再背一个大目标检测模型。而且GO2官方SDK给模块化开发留了接口把感知放在Orin上后续想换模型、加传感器都不用动机器人主控程序调试时也不用每次都抱着机器人来回跑。这套方案的结构一句话就能说明白GO2负责运动和底盘Jetson Orin负责看两边通过中间层通信协作。YOLOv5在这里扮演的是“眼睛的识别能力”不是普通图像显示而是把画面变成结构化信息。比如画面里出现一个“person”YOLOv5输出类别、置信度、bbox坐标我再把坐标换算成相对机器人的方位交给下一个控制模块。1.2 硬件拓扑与通信链路连接方式上我最初试过直接把Orin塞到GO2的载荷仓里用网线对接后面发现日常调试其实有更轻的办法。我的最终接法是Jetson Orin通过USB/以太网转接板和GO2主控建立连接同时Orin自身挂一个USB摄像头或者直接用GO2机身自带的RGB相机图像流。 注意不同批次GO2的支持情况有区别如果你拿到的是普通消费者版对底层传感器数据的访问权限可能有限这种情况建议走开发者版或先确认SDK权限。通信协议上宇树对二次开发一般提供两种通道一是基于UDP的实时指令通道用于发运动控制指令二是基于共享内存或Socket的图像/状态通道。我在Orin上单独跑了一个通信线程只负责接收GO2发来的图像帧和控制状态处理完的识别结果再通过UDP回发。这样做的用意是避免视觉推理阻塞运动控制指令二者解耦后无论是调试还是后期扩展都会舒服很多。这里多提醒一句如果是接着同一路由器调试务必把Orin和GO2主控设置到同一网段否则UDP广播根本到不了。我第一次配的时候被这个问题耗了一个晚上后面在抓包时才反应过来连接本身一点问题没有纯粹是IP网段冲突。2. Jetson Orin环境搭建2.1 JetPack版本的选择Jetson Orin这块平台比较特殊它虽然有完整的Ubuntu系统但驱动、CUDA、cuDNN、TensorRT这些不是自己一个个装的而是统一由NVIDIA的JetPack SDK管理。第一次使用SDK Manager刷机时我遇到的现象是系统烧录成功但nvidia-smi没输出查了半天才发现Orin上不能沿用PC上那套“装NVIDIA驱动”的思维只要刷机到JetPack 5.1.2或更高版本CUDA环境其实已经自带在系统里了。版本选择上我目前用的是JetPack 5.1.3搭配Ubuntu 20.04。这个组合的好处是生态最稳大部分AI组件都有预编译好的ARM版本。JetPack 6.0的底层是Ubuntu 22.04版式更新但有些第三方库官方wheel还没跟上部署YOLOv5时容易在torchvision编译环节翻车。所以如果你不是为了尝鲜新特性我建议还是稳扎稳打用JetPack 5.x。刷完系统后第一件事不是急着装包而是打开终端确认CUDA、cuDNN、TensorRT这些组件是否都正常注册。这里有一个小技巧直接运行dpkg -l | grep cuda看包列表如果只看到解压状态但未配置就用sudo dpkg --configure -a修复一下。这类问题多半是刷机过程断电或网络中断造成的不解决后面装PyTorch时会出现一堆莫其妙的链接错误。2.2 PyTorch与torchvision安装的坑YOLOv5的基础框架是PyTorch所以它在Jetson上的安装是整个部署流程最关键的一步也是翻车率最高的地方。很多习惯PC开发的初学者第一反应是pip install torch torchvision在Jetson上这招基本必挂。原因很简单Jetson的CPU架构是ARM64CUDA版本与PC不完全一致pip默认从PyPI拉下来的预编译包往往不适配要么找不到CUDA设备要么运行到一半直接段错误。正确做法是安装NVIDIA为Jetson平台专门打包的PyTorch wheel版本号要严格对应JetPack。比如JetPack 5.1.3对应torch 2.1.0和torchvision 0.16.0这套组合我实测跑YOLOv5是稳定复现的。安装命令虽然是一行pip但有个细节一定不要先装系统自带的torch先建一个干净的conda或venv虚拟环境再把wheel文件放进去安装隔离性会好很多。torchvision装好之后顺手跑一段测试代码确认torch.cuda.is_available()返回True。如果返回False可能不是torch的问题而是用户权限导致无法打开GPU设备需要在登录配置里加一行export CUDA_VISIBLE_DEVICES0或者检查当前用户是否在video用户组里。这个坑在Orin NX上尤其容易出现因为它默认的权限策略比AGX Orin严格一些。2.3 功耗模式与性能模式设置Orin类设备出厂时默认工作在“低功耗模式”目的是防止散热不够导致过热重启。但这种模式对AI推理性能的影响非常明显我的实测是YOLOv5s在默认模式跑帧率只有全速模式的六成不到GPU利用率也上不去。第一次用的时候我还以为是模型导出出了问题后来才发现是功耗墙卡住了。在Jetson设备上可以用nvpmodel -m查看和切换功耗模式。不同型号的Orin支持的模式编号不一样比如AGX Orin常见的MaxN模式对应nvpmodel -m 0。切换后建议再用jetson_clocks --fan打开风扇全速短时间满载推理时温度能压住性能会稳定很多。这里要特别说明一个容易混淆的问题nvpmodel和jetson_clocks不是一回事。nvpmodel决定CPU/GPU的频率上限和功耗上限jetson_clocks则是强制锁定某一时刻的时钟频率不锁的话系统会根据负载动态调频。做性能测试时我会两个一起用确保模型跑出来的数据是稳定可比的平时部署则可以只设置功耗模式让系统自己动态调度续航和发热更均衡。3. YOLOv5训练与TensorRT导出3.1 模型选型YOLOv5有几个常用版本n/s/m/l/x参数量和计算量递增。在Jetson平台上我的推荐排序是实时性优先用YOLOv5s精度优先用YOLOv5mn版虽然轻量但小目标检测效果下降太多不太适合机器人这种场景。x版在Orin上虽然也能跑但帧率收益不高边缘设备上没必要纠结那点精度差异。如果你是做室内巡检或特定物体识别强烈建议不要直接拿官方COCO预训练权重上线而是先在本地用你自己的数据微调。COCO那80类对四足机器人场景来说太泛了我看过很多人部署完demo实际到现场看到一个新类别物体完全无反应就是因为类别的定义跟场景不匹配。即便没有多少数据每类收集三五十张图做微调效果都会有质的提升。微调时还有几个超参数值得单独调学习率建议从0.01开始下降不要用默认的0.001硬套不然收敛太慢batch size在Orin上训练时不要开太大AGX Orin跑yolov5s的话batch16算是个安全值batch32可能直接显存溢出。图像输入尺寸也别一味调到640机器人场景下320或416的输入往往已经够用推理速度能快接近一倍。3.2 训练时的关键参数数据标注和格式整理是另一个隐藏的坑。YOLOv5用txt格式标注文件夹格式要求是images和labels一一对应并且每个训练目录下都要放对应的data.yaml文件。我最开始直接把公开数据集一股脑丢进训练目录里结果训练了一百轮后mAP一直不动排查发现是类别号没有从0开始编号导致标签和类别名称错位。训练命令我用的是官方仓库提供的train.py但并不是直接跑默认参数。我建议至少加上--cos-lr和--label-smoothing 0.1这两个参数对机器人这种比较单调的场景泛化能力提升明显。另外--patience参数可以设小一点比如20这样当验证集mAP连续多轮不再提升时自动停止省电也省时间。训练完成后记得转成ONNX或者TensorRT之前先验证一下val.py的结果主要看Precision、Recall和mAP_0.5。如果mAP_0.5在0.9以上说明模型效果可接受不用追求太高如果是0.8以下建议先检查数据集而不是急着调部署流程。我见过很多人把大量时间花在部署上最后发现模型精度本来就不行再改部署方案也是白搭。3.3 导出TensorRT引擎YOLOv5训练出来的weight文件是PyTorch格式直接放到Orin上跑虽然能用但速度不够理想。为了吃满TensorRT的加速能力需要把它转成TensorRT的engine格式。最省事的方式是YOLOv5官方仓库自带的export.py训练好的best.pt直接输入加上--include engine参数再根据平台情况选择--half或--int8。TensorRT导出时的坑集中在“动态尺寸”和“固定尺寸”的取舍上。我建议在机器人应用场景里直接用固定尺寸比如640×640或416×416这样可以大幅提升后续推理速度。如果一定要支持动态尺寸就要在导出参数里显式设置最小/最优/最大尺寸否则后续推理会报“input shape not match”之类的问题。有件事必须提醒TensorRT的engine文件和依赖的CUDA、TensorRT版本强绑定。同一个engine文件从一台机器复制到另一台机器基本跑不了哪怕系统版本一样也可能报“could not find any supported formats”的错。所以部署到多台Orin时老老实实在每台机器上分别导出一次不要想着复制文件省事。4. 摄像头数据接入与检测推理链路4.1 从GO2获取图像GO2机身上有摄像头但取流方式和普通USB摄像头不一样。宇树SDK提供的图像数据是YUV或BGR格式的裸流如果你按普通摄像头那套V4L2去调用大概率是失败的。正确做法是调用SDK里专门的图像接口将图像数据解包后转成numpy数组再交给YOLOv5预处理。这里有一个格式转换的坑YOLOv5默认输入是三通道RGBBGR序还是RGB序直接影响检测效果。如果你发现识别结果准确率低得离谱大概率不是模型问题而是图像的通道顺序反了。我第一次接入时忘了转换YOLOv5把R和B通道对调结果检测结果里正常物体全被认成了背景或错类物体。获取图像后建议先将原图复制一份用于后续的显示和回传不必直接修改原始帧。因为在机器人场景中原始画面还有可能要被SDK写进日志或回传上位机你不能为了推理把原始图像改得面目全非。这里我一般用一个双缓冲队列一个缓冲给推理线程消费另一个缓冲给主线程显示避免共享变量互斥时拖慢主流程。4.2 预处理与推理循环YOLOv5的预处理包含几个固定步骤调整图像尺寸到640×640、归一化到0-1、转成CHW格式并增加batch维度、放到GPU上。这些步骤在PC上不算事儿但在Jetson上有性能讲究不要每一次推理都用CPU做resize和归一化而应该用CUDA加速。OpenCV的cv2.dnn模块或者TensorRT的预处理层都能做但最稳妥的是在导出engine时把预处理层一并融合进去。推理循环方面我建议采用一个独立的线程或进程不要和通信模块写在同一个大循环里。因为YOLOv5推理虽然快但单帧耗时仍然可能达到10ms级别如果通信和控制逻辑等它整个系统的实时性都会变差。我实现时把推理线程设置为最高优先级通过队列向前端发布检测结果前端只消费最新一帧不需要处理积压数据。后处理是整个流程中比较容易忽视性能瓶颈的地方。YOLOv5输出的原始tensor包含大量候选框需要做置信度阈值过滤和NMS非极大值抑制。如果使用PyTorch自带的NMS在Orin上可能会因为CPU限制成为瓶颈。我在部署时干脆自己写了一个轻量NMS调用CUDA核函数配合固定阈值后续延迟从20ms降到了6ms左右。4.3 结果回传与控制联动识别结果回传是整套系统能否真正落地最后一环。如果只是把YOLOv5跑起来屏幕上画几个框那部署任务其实才完成一半。真正的联动场景是当检测到某个目标进入视野机器人要转身或接近目标。这一步需要把归一化坐标转换成机器人坐标系下的方位角再通过UDP指令发给GO2主控。换算公式不复杂把检测框中心的图像坐标映射到底盘坐标系再结合YOLOv5输出框的宽度估算距离。比较粗糙的方案是直接用图像中心与画面中心的水平偏差线性映射成旋转角速度这个思路对原型验证完全够用不需要精确标定。但如果是做抓取或避障这类高精度操作就得做相机内参标定和外参标定了。这里有一个部署级别的原则控制指令必须走独立的通道并且要有超时保护。我遇到过Orin推理卡住2秒结果GO2按照最后一次指令继续转圈的情况。最后加了看门狗机制如果连续500ms没有收到新的识别结果机器人就自动进入待机状态优先级安全第一。5.性能调优与踩坑记录5.1 帧率与延迟的实测数据我在自己的AGX Orin上实测了一组数据配置是JetPack 5.1.3、TensorRT FP16、YOLOv5s输入分辨率640×640。在不开启TensorRT的情况下PyTorch直接推理大概是30-35ms一帧导出TensorRT后能压到12-16ms一帧提升非常明显。如果是YOLOv5n分辨率降到416帧率能到70 FPS以上但小物体漏检率明显上升不建议在用GO2近距离巡检时用。Orin NX那边我也试过性能大概是AGX Orin的60%-70%。如果预算有限但又要跑YOLOv5Orin NX配YOLOv5s是个性价比不错的选择但建议把分辨率控制在480或者416能稳住30 FPS。再往上提分辨率Orin NX的GPU显存占用就有点吃紧了容易出现推理延迟抖动。延迟还要区分“单帧推理延迟”和“端到端延迟”。单帧推理延迟指的是GPU从拿到输入到输出检测结果的耗时端到端延迟还包括图像从GO2传到Orin、预处理、后处理、UDP回传等各环节。我实测端到端延迟会比单帧推理多出30-50ms这部分主要花在网络传输和图像格式转换上。如果需要降低端到端延迟建议采用共享内存或让Orin直接接相机避免整个图像数据频繁跨进程拷贝。5.2 常见坑及排查表我在部署过程中遇到过的比较典型的问题整理成一个速查表你可以直接对照排查现象可能原因解决办法torch.cuda.is_available()为False当前用户权限不足或JetPack组件安装不完整加入video组确认CUDA包已configure执行dpkg修复YOLOv5训练时显存溢出batch size过大调小batch size开启AMP混合精度训练TensorRT导出报模型结构不支持动态尺寸定义不完整导出时固定输入尺寸不启用动态shape检测准确率低但训练时mAP正常图像BGR/RGB通道顺序反了推理前对图像做通道转换验证像素值顺序GO2运动控制响应延迟大控制指令和推理共用同一个循环将控制和推理拆成独立线程控制线程优先级更高Orin推理时温度过高降频散热能力不足或风扇未开启设置功耗模式开启风扇全速外加辅助散热模块推理过程程序直接崩溃TensorRT engine与当前环境不匹配在每台设备上重新导出engine不要跨设备复制排查表看着简单但每一条背后都可能是一个通宵。尤其是TensorRT导出那种“要么全对要么全部跑不起来”的性格遇到报错时不要慌先回到基础环境校验再试官方demo逐步缩小范围比盲目改代码有效得多。5.3 我的几条真金白银经验说到底这类边缘部署项目最考验的不是某一步有多难而是整个链路里环环相扣的细节。第一次上手的人通常会低估GO2取流这个环节的麻烦总以为“接个摄像头而已”结果卡在SDK文档不完善、图像格式不清楚这些看似低级的问题上。我的建议是动手前先把GO2 SDK里的示例代码跑通一次不要一上来就搭整个系统模块单独验证能帮你省掉大量排查时间。系统规划上我强烈建议把通信、推理、控制、日志四个模块彻底解耦。每个模块做成独立进程或者独立线程模块之间只通过队列或消息传递数据。这看似增加了一点代码量但后续调试时优势太大了推理崩了通信还在通信断了推理照跑日志能清楚记录故障点。最后一个小技巧也是我踩过几次坑之后摸索出来的部署完成后一定要把固件版本、JetPack版本、所有关键依赖包版本写进一个部署文档里最好连同TensorRT导出的参数、环境变量一起记录下来。不要以为这很麻烦。等到三个月后需要重新刷一台设备或者遇到一个只在特定版本出现的问题你就会发现这份文档简直救命。