先说个结论宇树GO2上跑YOLOv5这件事难点根本不在算法而在三个地方——环境配对、TensorRT加速、还有机器狗数据通路的打通。任何一个环节没理顺都会让你在明明照着教程做了的情况下浪费一整天。这篇文章把我从零开始把YOLOv5部署到Jetson Orin、再接入宇树GO2的完整过程写出来包括每一步踩过的坑和最终的解决方式。如果你正在做四足机器人上的目标检测开发或者准备在Jetson系列设备上本地跑视觉模型这篇应该能帮你省掉不少弯路。1. 先想清楚为什么必须在Jetson Orin上跑YOLOv51.1 GO2自带算力模块的真实水平宇树GO2本体自带一个计算模块负责任地说它足够跑运动控制、姿态解算、SLAM建图这些基础任务日常表现也很稳。但如果你想在它上面直接跑YOLOv5做实时目标检测马上会遇到两个尴尬第一算力资源吃紧。GO2内置模块的主CPU和内存都是为运动控制设计的跑一个未经加速的YOLOv5推理帧率会掉到个位数而且一旦检测线程卡顿还可能影响运动控制线程的实时性造成功控不稳甚至摔机。四足机器人这种平台运动安全永远比检测性能优先级高。第二生态封闭。宇树官方提供的SDK主要面向运动控制和状态读取并没有开放足够的GPU计算资源给第三方模型跑。就算你想硬塞驱动和库的兼容性也够折腾。所以最合理的方案就是外挂一块Jetson Orin把它当作机器狗的感知副脑GO2负责走和保持平衡Jetson Orin负责看和理解。两者通过局域网通信各干各的活互不干扰。1.2 整体系统架构怎么搭我采用的架构是这样的宇树GO2自带相机 运动控制SDK │ │ 局域网有线连接优先Wi-Fi次之 ▼ Jetson AGX OrinYOLOv5推理 TensorRT加速 │ │ 根据检测结果计算速度指令 ▼ 通过SDK将速度指令发回GO2这套架构有几个明显的好处算力解耦GO2的运动控制完全不受视觉推理影响反过来视觉推理也能独占Orin的全部GPU算力。便于调试模型更新、代码改动都只在Orin上进行不需要频繁刷写GO2固件调试效率高很多。可扩展性强以后想换SegNet、YOLOv8或者跑多模态模型只要Orin侧改就行跟机器狗本体无关。通信方式上强烈建议优先用有线以太网直连而不是Wi-Fi。原因很实在之前我用Wi-Fi测试时图像传输延迟波动很大偶尔还会出现丢帧实测延迟能到80-120ms。换成有线直连后延迟稳定在10ms以内。四足机器人运动场景讲究实时反馈10ms和100ms的差别直接决定了你的避障逻辑是来得及还是已经撞上去了。2. 环境搭建JetPack、PyTorch、torchvision的版本配对是第一道坎2.1 刷机与JetPack版本选择Jetson Orin拿到手第一件事是刷机用NVIDIA SDK Manager刷JetPack。这里我踩的坑是版本选择一开始图新鲜装了最新版JetPack 6.0对应Ubuntu 22.04结果发现几个常用依赖在aarch64架构下的wheel包还不齐YOLOv5跑起来各种报错。后来退回到JetPack 5.1.2对应Ubuntu 20.04一切才顺畅起来。这不是说JetPack 6不好而是对于YOLOv5这种已经非常成熟的模型来说5.1.2的配套生态明显更完整PyTorch官方wheel、TensorRT 8.5.2、OpenCV预先编译好的arm64包全都是现成可用的不用自己操心源码编译。给新手一个建议别追新版本选生态最成熟的版本。边缘设备不像云服务器装环境翻车一次的成本很高重刷系统加重新配置的代价足够让你心疼半天。2.2 PyTorch安装不要在Jetson上直接pip install torch这句话我写三遍都不嫌多不要在aarch64的Jetson上直接pip install torch不要在Jetson上直接pip install torch绝对不要。为什么因为PyPI上默认的torch包是x86_64架构编译的Jetson是ARM架构aarch64直接pip会触发源码编译。我一同事试过一次编译了三个多小时最后在编译到一半的时候OOM内存溢出挂掉了连个像样的错误日志都没留下。正确做法是从NVIDIA官方提供的预编译whl包安装。以我的环境为例# JetPack 5.1.2Python 3.8 pip install torch2.0.0nv23.05 -f https://developer.download.nvidia.com/compute/redist/jp/v512/pytorch/ pip install torchvision0.15.0nv23.05 -f https://developer.download.nvidia.com/compute/redist/jp/v512/pytorch/装完必须验证一下CUDA是否可用import torch print(torch.__version__) # 2.0.0nv23.05 print(torch.cuda.is_available()) # 必须为True print(torch.cuda.get_device_name(0)) # 应显示Orin的GPUNVIDIA官方把这些wheel放在了开发者网站从官网下载就行。注意torch和torchvision的版本必须严格对应这套对应关系在官方whl索引里写得清清楚楚照着选即可。2.3 YOLOv5官方依赖的坑YOLOv5的环境配置其实不复杂但它有一个老毛病requirements.txt里的依赖版本约束比较宽松装出来的环境不一定靠谱。我遇到的几个典型问题OpenCV的坑requirements.txt里写的是opencv-python4.1.2这个包在aarch64平台会拉取一个体积巨大的wheel大约200MB安装慢不说还容易与JetPack系统自带的OpenCV冲突。我的处理方式是不装pip版OpenCV直接用系统自带OpenCV在requirements.txt里把opencv-python那行注释掉。系统版OpenCV是NVIDIA针对JetPack优化过的支持CUDA加速解码实际体验更好。numpy版本问题YOLOv5在检测时用到了np.clip、np.interp等API如果numpy版本过低或过高某些第三方依赖比如matplotlib、pandas、seaborn会报奇奇怪怪的兼容性错误。我的建议是装numpy 1.24.3或者更早的1.23.x别用numpy 2.xYOLOv5 v7.0在numpy 2.x下会直接报np.int移除的错误。Python虚拟环境一定要用conda或venv隔离环境我的选择是miniconda。直接在系统Python里装YOLOv5的依赖时间和心态都会受到双重考验——各种库互相打架是常态你很难分清是哪个依赖污染了系统环境。而且四足机器人开发中你可能还要装其他工具包隔离环境可以避免它们互相干扰。3. YOLOv5部署实录从pt权重到TensorRT引擎的完整链路3.1 用PyTorch直接推理跑通环境在折腾TensorRT之前先用YOLOv5的PyTorch模式跑通训练好的模型是必要的。这一是为了验证环境二是给自己一个性能基准线——之后TensorRT加速效果好不好对比的是这个基线。git clone -b v7.0 https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt # 记得先注释opencv-python权重从官方发布页下载我测试时选的是YOLOv5s和YOLOv5m两个尺寸。如果你是第一次在Jetson上跑建议先下YOLOv5s它权重小14MB推理速度快先把整条链路跑通再考虑换更大的模型。官方权重默认是在COCO数据集上训练的检测80个类别对大多数机器人场景够用。如果你要检测特定目标比如检测着火点、特定货物或者某种动物就需要用官方权重做迁移学习在自己的数据集上微调这个后面单独讲。先用一张测试图片验证import torch model torch.hub.load(ultralytics/yolov5, custom, pathyolov5s.pt, force_reloadTrue) results model(test.jpg) results.show()如果环境没问题你很快就能看到检测框输出。这时顺带记一下PyTorch推理的耗时后面对比用。3.2 ONNX导出opset和动态shape的坑YOLOv5要转TensorRT中间必经一步是转成ONNX。这一步踩坑概率极高主要问题集中在opset版本和动态shape两方面。YOLOv5官方提供了export.py脚本python export.py --weights yolov5s.pt --include onnx --opset 12这里我用的是opset 12是TensorRT 8.5.2支持最佳的版本。试过opset 16甚至17TensorRT转换时有些算子不支持或被降级处理速度反而不如opset 12。关于动态shape有一个经典的选择陷阱。export.py默认导出动态宽高dynamicTrue意味着ONNX模型接受任意尺寸的输入。听着方便但转入TensorRT时动态shape会导致引擎做了很多次优化性能和内存都不理想。我的做法是直接固定输入尺寸640x640python export.py --weights yolov5s.pt --include onnx --opset 12 --imgsz 640 640固定尺寸有几个好处TensorRT可以针对该尺寸做内核级优化推理延迟更稳定engine文件也更小。缺点是不能随便换输入尺寸但YOLOv5的letterbox预处理本来就会把任意尺寸的图片统一缩放640x640对大多数机器人场景的探测距离和性能平衡是最好的。导出ONNX后还有一个常见的坑如果发现导出的ONNX模型在后续转TensorRT时某些算子在GPU上运行错误可以尝试--simplify开ONNX简化去掉一些冗余计算节点。官方脚本默认不开启我用的时候明显感觉简化后的模型解析更顺利。3.3 TensorRT转换trtexec和pycudaONNX转TensorRT最直接的方式是用TensorRT自带的trtexec命令行工具这个工具不用写一行代码/usr/src/tensorrt/bin/trtexec \ --onnxyolov5s.onnx \ --saveEngineyolov5s_fp16.engine \ --fp16这里解释一下为什么用FP16而不是FP32或INT8FP32最稳精度最高但在Orin上浪费了FP16吞吐翻倍的特性延迟偏高。FP16精度损失可以忽略而计算速度几乎翻倍显存占用减半是最推荐的均衡点。INT8理论上更快但需要准备校准数据集且YOLOv5中的某些层对INT8量化敏感容易掉精度部署周期明显拉长。实测下来YOLOv5s在FP16下单张640x640图像的推理延迟稳定在10ms左右比PyTorch FP32快3-4倍这个结果已经完全满足机器狗实时感知的需求了。engine文件生成后在Python中需要通过TensorRT的API加载推理。YOLOv5的engine推理和PyTorch推理在这步开始分道扬镳engine不像PyTorch模型那样可以直接输入numpy数组你需要自己处理内存分配和显存拷贝。这一步我用pycuda简化了流程核心代码结构大概是这样import tensorrt as trt import pycuda.driver as cuda import pycuda.autoinit logger trt.Logger(trt.Logger.INFO) runtime trt.Runtime(logger) with open(yolov5s_fp16.engine, rb) as f: engine runtime.deserialize_cuda_engine(f.read()) # 申请输入输出缓冲区 input_buf cuda.mem_alloc(input_size) output_buf cuda.mem_alloc(output_size)TensorRT还有一个关键点engine文件与GPU型号严格绑定。在AGX Orin上转出来的engine文件不能拿到Orin NX上直接跑反过来也不行。换设备必须重新转换这是设计决定的不是bug。4. 宇树GO2的SDK对接把机器狗相机画面送进推理链路4.1 通信链路与SDK选择Jetson Orin部署好了YOLOv5也能跑了接下来最关键的一步就是把宇树GO2的数据接进来。宇树提供了一套跨平台的SDK同时支持C和Python用Python最方便改代码不用重新编译。SDK的获取方式是从宇树官方GitHub仓库直接拉取里面有完整的代码示例和文档说明。通信链路是这样的GO2开启无线或有线通信模式后会在局域网内暴露多个数据话题SDK客户端通过指定IP和端口订阅这些话题。我的习惯是用有线直连的方式把Orin和GO2连在同一个交换机上网段固定配置避免Wi-Fi的信号抖动影响图像传输。SDK里可以订阅的数据包括机器人状态、运动控制反馈、电池电量以及最重要的——相机图像流。宇树GO2机身上有多个摄像头我用的主要是前方主摄像头。订阅图像的话题后SDK回调里会周期性收到编码好的帧数据。4.2 图像数据格式的坑鱼眼、BGR、帧率这里是全程我认为最容易踩的坑数据格式问题分三层第一层是镜头畸变。GO2的相机是鱼眼镜头视角大但画面边缘畸变明显。YOLOv5官方训练使用的VISDRONE或COCO数据集都是常规镜头画面直接把鱼眼帧扔给YOLOv5边缘区域的目标很容易产生漏检。我的处理方式是先对输入帧做去畸变校正OpenCV的fisheye模块有现成接口拿到相机的内参后一行代码就能校正。不过这一步需要多花一点点CPU时间大约3-5ms对于不是特别追求边缘检测率的场景可以先不做后期再优化。第二层是颜色通道。GO2的SDK拿到的帧一般是BGR格式而YOLOv5在PyTorch训练时用的是RGB通道。这个坑很隐蔽不一定报错但检测效果会明显变差。在把图像送入模型前必须做一次通道转换frame cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)第三层是帧率与分辨率。GO2相机默认输出30fps但YOLOv5部署在TensorRT FP16下大概能在40-60fps之间运行。如果直接把所有帧都送进去推理CPU和内存压力会非常大而且控制指令的发送频率也不需要那么高。我的策略是设置一个推理频率上限比如10-15Hz多余的帧直接跳过。运动控制指令的更新频率也可以降到20Hz这与视觉检测频率错开避免系统资源竞争。4.3 推理结果如何变成机器狗的动作检测出目标后下一步是把结果转成宇树GO2能理解的控制指令。这是整个系统逻辑最核心的一环我做的是这样一套基础逻辑通过bbox中心点x坐标判断目标在画面中的左右位置决定机器狗转向方向和速度。通过bbox面积大小估算距离远近面积大说明近需要减速或者停止面积小说明远可以全速靠近。检测到目标类别时控制机器狗跟随目标没有检测到目标时原地旋转搜索。用SDK发送速度指令非常直接调用SDK里封装好的接口就行# 伪代码示意具体接口以SDK文档为准 sdk.set_velocity(vx0.3, vy0.0, w0.5)vx是前进速度w是旋转角速度。四足机器人的运动控制在这套SDK里封装得很好你不需要关心每条腿怎么出力只要给期望速度就行。调试期间务必注意安全。我一开始直接在平地上测试发现机器狗在检测到目标后加速过猛差点撞到人。后来在代码里加了硬限制最大前进速度不超过0.5m/s遇到检测到的目标距离小于阈值时直接停车。建议大家在测试初期也这样做先保证安全再调性能。5. 实测性能与调优建议5.1 不同配置下的推理延迟对比为了让大家直观了解Jetson Orin上的性能表现我把测试过的配置和延迟数据整理成了一张表模型推理方式输入分辨率平均延迟(ms)帧率(FPS)YOLOv5sPyTorch FP32640x6403231YOLOv5sTensorRT FP16640x6401190YOLOv5mPyTorch FP32640x6405817YOLOv5mTensorRT FP16640x6402245YOLOv5sTensorRT FP161280x12803528数据是在Jetson AGX Orin 64GB上测的功率模式默认MAXN。可以看到TensorRT FP16的加速效果非常明显YOLOv5s的推理延迟从32ms直接降到11ms这还是在包含前处理、NMS后处理的全流程耗时。如果你用的是Jetson Orin NX 16GB性能大约要打六折YOLOv5s TensorRT FP16延迟大约在18-20ms左右也能满足实时性要求。但Orin Nano8GB就比较勉强了YOLOv5s FP16延迟大约30ms以上建议只跑YOLOv5n或者降低输入分辨率。5.2 功耗、显存和长时间运行稳定性边缘部署和服务器部署最大的区别在于功耗和散热约束。AGX Orin有多种功率模式最激进的MAXN模式功耗在40-60W性能最强但发热明显。我的实际经验是MAXN模式下跑YOLOv5s FP16GPU显存占用大约2.1GBCPU内存占用约1.5GB这个功耗对Orin来说没有压力风扇声音会明显变大。如果整机供电是电池方案建议限制为30W功率模式。实测推理帧率只降低了大约20%但温度和续航都友好很多。千万别忽略散热长期满负荷跑模型Orin的风扇如果被灰尘堵住或者环境温度过高会出现降频延迟会从11ms突然涨到40ms。长时间运行还有一个容易忽略的问题内存泄漏。Python的TensorRT推理脚本如果长时间不释放context或缓冲区吃了好几个小时之后内存可能会涨到异常水平。我的做法是写一个监控循环实时打印GPU显存占用如果发现持续增长优先检查后处理阶段有没有把图像数据重复保留及时清理不需要的缓存。5.3 最后整理一份避坑清单这份清单是整个过程踩坑的浓缩按顺序排下来假如你从零开始照着走应该能省掉大半的调试时间JetPack版本选5.1.2别用太新的版本等待社区把新版本的坑踩完再考虑升级。PyTorch用NVIDIA官方wheel绝不用pip直装。YOLOv5固定输入尺寸640x640做TensorRT转换提高引擎优化度。TensorRT用FP16精度不用INT8省去校准和精度调优的麻烦。GO2相机图像进模型前先做BGR转RGB别觉得这是小事。用有线连接GO2和Orin别用Wi-Fi测试延迟和丢帧会让你怀疑是代码写错了。机器人控制指令加上速度上限和距离硬停止逻辑测试安全第一。设备间转移必须重新生成engine文件不能直接拷贝。最后再分享一个我个人实际操作中的体会宇树GO2和Jetson Orin的结合其实是四足机器人感知开发的一个很典型组合。如果你之前用过其他机器狗平台会发现宇树的SDK在API设计上算是把运动控制和数据访问封装得比较省心的但越省心就越容易让人忽略底层数据链路的细节。图像格式、通信延迟、推理引擎的选型这些东西每一个单独看都不难但串在一起的时候牵一发而动全身。我把自己的部署过程毫无保留地写出来也是希望大家不要在这些基础设施问题上浪费太多时间把精力真正放在算法逻辑和应用场景上。