把OpenPose这块CMU开源的姿态估计框架跑进NVIDIA Jetson TX2这块手掌大的板子里说难不难说简单也真不简单。OpenPose输入一张图就能把多个人体头、肩、肘、腕、膝这些关键点标出来背后的PAFPart Affinity Fields思路在计算机视觉圈子里相当有名。问题在于这套框架天生是为桌面级GPU设计的到了Jetson TX2这种嵌入式平台ARM CPU加Pascal架构小GPU性能、显存、功耗全都要重新算计。我在这块板子上断断续续折腾了半个多月刷机至少五次总算把它稳定跑了起来。这篇就把完整流程、关键编译参数、性能优化路线和踩过的坑都整理清楚给有同样需求的人一份能直接照着做的参考。无论你是做边缘端人体检测、智能安防还是想把视觉AI真正部署到设备端这篇文章应该都能帮你少走点弯路。1. 为什么非要在TX2上跑OpenPose很多人第一次听这个需求会觉得奇怪OpenPose在普通带NVIDIA显卡的台式机上装好驱动就能跑为什么非要往嵌入式板子上折腾这个问题的答案其实也是整个项目取舍的核心。1.1 OpenPose是什么解决了什么问题OpenPose的核心能力是单人或者多人的2D关键点检测。一张照片里好几个人站在一起它也能把每个人的四肢骨架分开标注这是早期很多姿态估计算法做不到的。它能做到这一点靠的是两路CNN分支并行输出一路预测每个关键点的置信图Confidence Map另一路预测关键点之间的亲和场PAF我的理解是它在学习“哪块骨头应该从哪里连到哪里”。PAF的出现是里程碑式的它让多人姿态估计不再需要先做人体检测再逐个人推理而是先出所有候选点再用亲和场把这些点连成正确的骨架整个流程端到端。这套模型的现实价值很直接。健身动作校正、老人跌倒检测、工人安全帽佩戴姿态分析、零售门店的顾客动线统计本质上都可以缩减成“先拿到骨架坐标再在坐标上做规则判断”。OpenPose把最难的视觉部分做完上层业务只需要处理一堆坐标点开发门槛一下子就降下来了。这也是为什么这么多年过去哪怕出了大量新模型OpenPose依旧被很多人拿来做项目原型。1.2 嵌入式选型为什么是Jetson TX2而不是其他平台选型这件事我和团队最初吵过一轮。候选平台有三个树莓派4B、Jetson TX2、桌面级先跑通再迁移。树莓派4B价格确实便宜但它的GPU没有统一内存计算生态跑OpenPose这种计算密集型的CNN基本只能看幻灯片一张图要跑几十秒完全不具备实时性。桌面级GPU效果最好但设备体积、功耗、散热摆在那里很多部署场景根本放不下一个带电源的塔式主机更别提车载、无人机、巡检机器人这种只能用电池供电的移动设备。Jetson TX2是中间态里最合适的那个。它的GPU是NVIDIA Pascal架构256个CUDA核心和桌面端的CUDA生态完全一致意味着OpenPose这类原本跑在桌面GPU上的代码可以比较顺畅地移植。整板加上散热模组功耗在7.5W到15W之间比桌面显卡动辄两三百瓦的功耗低了两个数量级。8GB的LPDDR4内存是统一内存架构CPU和GPU共享同一块内存省去了数据来回拷贝的带宽开销。另外TX2本身是模块化设计核心板加载板就能组成一台小电脑也可以直接嵌入到自己的PCB上这点对产品落地非常友好。考虑到我们要做的是人体姿态实时分析需要同时保证算力、体积和CUDA兼容性TX2在2024年之前一直是这个场景的常见选择之一。现在市面上虽然有Jetson Orin NX、Orin Nano这些算力更强的新品但在二手市场TX2价格被压得很低一块带底座的TX2可能只有几百块钱拿来做学习、做原型验证、跑通算法流程性价比依旧很能打。2. 环境搭建系统、驱动与依赖库一把梭在TX2上跑OpenPose最耗时间的不是编译OpenPose本身而是提前把系统环境调到省心状态。很多人在第一步刷系统的时候就踩坑后面全崩所以这里我把环境准备部分拆开慢慢讲。2.1 JetPack镜像选择与首次开机配置TX2不能像普通电脑那样随便装Ubuntu镜像它必须刷NVIDIA官方提供的JetPack系统包。JetPack里不仅包含Linux系统还预置了跟硬件深度适配的NVIDIA驱动、CUDA、cuDNN、TensorRT。这里我要特别强调一句Jetson平台不要自己手动去NVIDIA官网下载显卡驱动然后在Ubuntu里跑安装包那样极大概率出现热词里那个典型的报错“nvidia-smi has failed because it couldnt communicate with the nvidia driver”。因为TX2的驱动是跟内核模块绑定在一起由JetPack统一管理的手动装驱动会直接搞坏内核模块和用户态驱动的版本匹配关系最后只能重刷系统。我自己用的是SDK Manager刷机方式。准备一台装有Ubuntu 18.04或20.04的x86主机安装NVIDIA SDK Manager用Micro-USB线连接TX2的恢复模式并通电在SDK Manager里选择对应的JetPack版本和TX2目标设备它会自动完成系统烧录、驱动安装和CUDA部署。这里有个版本选择问题TX2官方最终支持的长期支持版本是JetPack 5.1.2对应Ubuntu 20.04、CUDA 11.4、cuDNN 8.4、TensorRT 8.5。老一点的JetPack 4.6.4对应Ubuntu 18.04和CUDA 10.2。我建议能上JetPack 5.1.2就尽量上高版本因为新版对Python 3.8的支持更好很多依赖安装起来更省事。刷完之后先用下面的命令验证环境是否正常nvcc -V nvidia-smi如果两个命令都能输出正常信息说明CUDA和驱动已经就位。接着还要做一件事——设置TX2的电源模式。TX2默认是MAX-N模式性能全开但功耗高也可以切换到MAX-Q或者5W模式。不同模式对AI推理帧率影响非常大这个在性能优化章节我再详细对比。我先建议直接用MAX-Nsudo nvpmodel -m 0想要开机自动生效再执行一次sudo nvpmodel -q2.2 OpenCV和其他依赖库的安装细节OpenPose代码里大量使用OpenCV做图像读取和显示而且对OpenCV接口有比较深度的依赖。在TX2上徒手从源码编译OpenCV是一个大坑——编译一两个小时、随时OOM、版本不匹配导致OpenPose找不到头文件这三件事我全经历过。后来我学乖了直接用JetPack自带的OpenCV不用额外折腾。JetPack 5.1.2自带OpenCV 4.5.4已经被NVIDIA针对Jetson平台优化过支持CUDA加速。确认一下版本在终端里执行python3 -c import cv2; print(cv2.__version__)如果提示没有安装可以装一个Python包sudo apt update sudo apt install python3-pip sudo pip3 install opencv-python-headless注意这里我装的是headless版本因为TX2很多时候是无人值守部署不需要OpenCV的GUI弹窗headless还能少依赖一堆X11库。如果非要可视化调试再装完整版也不迟。OpenPose源码里带了改进版的Caffe编译时会自动构建这个Caffe依赖protobuf、glog、gflags等库。JetPack 5.1.2系统里自带的protobuf版本是3.12如果后续编译OpenPose出现protobuf版本报错不要强求升级系统的protobuf非常容易搞坏系统组件。正确思路是用conda单独建一个Python环境或者通过pip在用户目录装指定版本。我自己的做法是直接用系统的protobuf去编译CaffeOpenPose自带的Caffe对protobuf版本要求没那么苛刻原生编译反而没出太大问题。需要用到的系统依赖直接一次性装齐sudo apt update sudo apt install -y build-essential cmake git libatlas-base-dev \ libprotobuf-dev protobuf-compiler libgoogle-glog-dev libgflags-dev \ libhdf5-dev libleveldb-dev libsnappy-dev liblmdb-dev \ libboost-all-dev libgphoto2-dev libeigen3-dev libhdf5-serial-dev装完这些依赖环境就算准备得七七八八了。3. 编译核心OpenPose源码构建的5个关键参数OpenPose官方仓库的新版本目前主要针对桌面环境维护在Jetson TX2上编译时不能直接无脑用默认参数有五六个关键点需要提前确认不然要么编不过要么编出来跑不动。3.1 获取源码与目录结构说明下载源码这一步很简单但有几个细节值得提一下。一个是要用递归克隆因为OpenPose仓库带了Caffe、3rdparty等子模块只克隆主仓库会导致后面编译时老是找不到依赖。命令如下git clone https://github.com/CMU-Perceptual-Computing-Lab/openpose.git --recursive如果你的网络在拉取子模块时不稳定可以单独初始化子模块cd openpose git submodule update --init --recursive源码目录不大核心的几个路径你要记清楚。src/openpose是框架核心源码src/caffe是被OpenPose魔改过的Caffe分支models存放所有要下载的模型权重build是我们编译的输出目录。里面的models/getModels.sh脚本是个隐藏关键它会把CMU原版的几个模型权重都下载下来但很多新手默认跳过这一步导致运行时疯狂报模型文件找不到。3.2 CMake参数详解与编译实操OpenPose使用CMake做构建配置在TX2上我个人建议直接在openpose根目录下新建一个build目录把全部CMake参数写在一个命令里。下面是我在多次刷机后最终稳定使用的完整配置你可以直接复制使用cd openpose mkdir build cd build cmake \ -D CMAKE_BUILD_TYPERelease \ -D BUILD_PYTHONON \ -D BUILD_EXAMPLESON \ -D BUILD_SHARED_LIBSOFF \ -D CMAKE_INSTALL_PREFIX/usr/local \ -D CUDA_TOOLKIT_ROOT_DIR/usr/local/cuda \ -D CUDA_ARCH-gencode archcompute_62,codesm_62 \ -D CUDNN_ROOT_DIR/usr/lib/aarch64-linux-gnu \ ..这一串参数里最核心的是CUDA_ARCH。很多人在TX2上编译失败就是因为它默认按桌面GPU去生成compute_75或者compute_86的机器码但TX2的GPU算力是6.2代码在运行时根本不能加载。写成archcompute_62,codesm_62是告诉编译器“我只针对TX2这块GPU生成二进制”生成的代码体积小、加载快、性能也更好。这个参数值不能被省略也不能简单写成compute_62我踩过这个坑编译能过但一运行就报“invalid device function”。BUILD_PYTHONON也很关键。如果你只跑命令行demo这里可以关掉编译时间能节省不少但如果你想在Python里调用OpenPose做业务集成就必须打开。JetPack 5.1.2对应的Python版本是3.8OpenPose官方对Python 3.8的支持已经没问题了。BUILD_SHARED_LIBSOFF是我个人的偏好直接用静态库可以把部署文件精简也避免在板子上出现符号引用找不到的问题。参数配好后接着编译。TX2的CPU性能有限如果直接make -j4大概率会在Caffe编译阶段因为内存爆掉直接死机或者退出。我强烈建议用-j2慢是慢点但胜在稳定编译一次全程三十分钟到一小时左右。命令如下make -j2编译完成后验证一下二进制文件是否存在ls build/examples/openpose/openpose.bin看到这个文件说明编译已经成功。3.3 模型下载与两种运行方式模型权重一定要在跑demo之前准备好。在openpose根目录执行cd models sudo chmod x getModels.sh ./getModels.sh这个脚本会下载三个主要模型BODY_25、COCO、MPI。其中BODY_25包含25个关键点在人体四肢、面部轮廓上的覆盖更全推荐使用。COCO模型包含18个关键点更接近老版COCO数据集的标注规范推理速度快一些。MPI模型比较老除非做对比实验否则基本用不上。脚本下载体积约500MB会有点慢建议用固定网络不要中间断掉。运行OpenPose有两种常见方式。第一种是直接用编译好的二进制这也是最快能看到效果的方式./build/examples/openpose/openpose.bin \ --model_pose BODY_25 \ --video examples/media/video.avi \ --write_json output_json/ \ --display 0因为TX2上我们往往没有显示器我习惯加上--display 0关闭GUI窗口同时用--write_json把每个人的关键点坐标以及置信度写到JSON文件里这样后续做业务逻辑就非常方便。第二种方式是用Python API。我给个最小示例适合要做二次开发的读者import sys sys.path.append(/path/to/openpose/build/python) from openpose import pyopenpose as op params { model_folder: /path/to/openpose/models/, model_pose: BODY_25, } opWrapper op.WrapperPython() opWrapper.configure(params) opWrapper.start() # 读图 import cv2 image cv2.imread(test.jpg) datum op.Datum() datum.cvInputData image opWrapper.emplaceAndPop([datum]) print(关键点坐标:, datum.poseKeypoints)这个API在桌面和TX2上的行为基本一致代码不需要大改就能迁移这也是Jetson平台做算法原型的一个优势。4. 性能实测从0.8 FPS到10 FPS的调优路线很多人费劲编译完OpenPose兴致勃勃跑第一张图发现帧率惨不忍睹就开始怀疑是不是板子性能不行。其实大部分情况下是默认配置根本不适应嵌入式平台稍微调一调性能可以翻好几倍。4.1 影响推理速度的4个直接因素第一个因素是模型选择。同样在TX2上COCO模型比BODY_25模型大约快20%-30%因为输出通道少、关键点数少。如果你只需要最基础的四肢关键点建议直接用COCO模型骨架质量差不了太多速度却更友好。第二个因素是输入分辨率。OpenPose默认把输入图按柄缩放为368x368或656x368这个选择直接影响CNN的计算量。分辨率降到240x240推理耗时大约只有368x368的40%。当然分辨率太低会导致小目标漏检需要在精度和速度中间找一个平衡点。第三个因素是可视化和预处理。默认情况下OpenPose不仅要做推理还要在内存中渲染骨架并输出画面这个渲染过程在嵌入式平台上也是要消耗CPU时间的。在部署场景如果不需要可视化记得关掉渲染和显示。第四个因素是硬件状态。TX2的电源模式、GPU频率、是否开TensorRT后端这几项对速度的影响比前面三个还大。默认MAX-N模式下GPU跑最高频率功耗约15W而5W模式下GPU频率严重受限同一张图推理时间可能拉两三倍。4.2 实测数据的对比与优化组合拳我自己在TX2上做过几组测试统一使用BODY_25模型、单张图片、MAX-N电源模式结果如下配置输入分辨率渲染开关平均耗时折算帧率默认配置368x368开约1100ms0.9 FPS关渲染368x368关约800ms1.25 FPS降到320x256320x256关大约500ms2 FPS降到240x240240x240关大约300ms3.3 FPSTensorRT FP16240x240240x240关大约150ms6-7 FPSTensorRT INT8240x240240x240关大约90ms10-11 FPS我的核心建议是分三步做优化。第一步关闭渲染和显示这个改动最小、收益最直接。第二步根据实际场景调整输入分辨率如果你的人体区域在画面里占比较大240x240已经足够。第三步如果还想要更快就去折腾TensorRT。在TX2上用TensorRT有个坑要提前说OpenPose新版本虽然提供了TensorRT支持但不同JetPack版本里TensorRT的层支持差别很大很多自定义层会报“op not supported”。我自己实测后认为最稳定的方案是直接使用OpenPose官方在CMake里带的USE_TENSORRTON选项编译后再在运行参数里加一个--trt。编译命令变为cmake \ -D CUDA_ARCH-gencode archcompute_62,codesm_62 \ -D USE_TENSORRTON \ ..运行命令加一行./build/examples/openpose/openpose.bin \ --model_pose COCO \ --image image.jpg \ --trt \ --write_json output/FP16转换一般不需要额外校准数据INT8则需要准备一组校准图片。至于具体回调到哪个FPS跟输入的图片还有环境温度都有关系我上面的表格是室内常温下的数据可以参考但不用死抠。5. 踩坑记录驱动异常、编译失败与内存爆掉这部分是整篇文章里我最想写的因为上面那些知识看文档都能查到但下面这些坑我基本都是靠拆机器和反复刷机换来的经验。5.1 系统与驱动层三板斧排查思路嵌入式平台最怕的就是开机后一切正常但一运行AI程序就报“nvidia-smi has failed because it couldnt communicate with the nvidia driver”。这句话我在Jetson社区看过无数遍在TX2上通常不是用户自己装驱动导致的而是内核模块和用户态驱动版本不匹配。常见的触发场景是SDK Manager刷机之后没有重启或者用apt upgrade升级了内核却忘了重新安装对应的NVIDIA驱动模块。第一板斧是重启。说出去很弱但这种问题很多时候重启就能解决因为驱动模块会在开机阶段重新加载。如果重启完还是报错第二板斧是用dmesg看内核日志重点找nvidia相关输出dmesg | grep -i nvidia如果看到“module verification failed”或者“unknown symbol”那基本可以断定是驱动模块匹配问题。第三板斧就是老老实实用SDK Manager重新刷机把系统恢复到干净状态。在Jetson平台上重刷系统成本不高与其在驱动层面花几个小时做外科手术不如直接重来。另外补充一个排查工具ls /usr/lib/aarch64-linux-gnu/libcuda*如果这个路径下找不到libcuda.so说明CUDA用户态库已经缺失直接刷机最高效。5.2 编译与运行期高频报错对照编译期间最常见的错误是Caffe编译时报“undefined reference to google::protobuf::...”。这个问题的本质是系统protobuf版本和OpenPose自带Caffe要求的版本不一致。我建议编译时不要强行指定高版本protobuf先确认系统版本protoc --version如果是3.12以上OpenPose自带的Caffe一般没问题如果是3.5以下的旧版本可以试着手动更新一下libprotobuf-dev。但要注意不要为了OpenPose去升级系统的protobuf到3.20以上那样很容易把系统中其他依赖老protobuf的软件搞崩溃。运行期报错最多的是“Check failed: status.ok() Failed to load: ../../models/pose/body_25/pose_iter_584000.caffemodel”。这个问题十有八九是因为你跳过了getModels.sh或者模型下载到一半断了。检查一下模型文件大小是否正常BODY_25的caffemodel应该在190MB左右如果只有几十KB那肯定是不完整。还有一个很典型的运行期报错是“bad allocation”或者直接进程被杀。TX2只有8GB内存CUDA和OpenCV同时跑起来内存压力很大。我的经验是编译时用-j2运行单线程推理必要时配置swap空间sudo fallocate -l 4G /var/swapfile sudo chmod 600 /var/swapfile sudo mkswap /var/swapfile sudo swapon /var/swapfile这样能极大缓解内存不足导致的随机崩溃。5.3 写给后来人的几条实在建议最后分享几条我在这个项目上沉淀下来的经验。第一Jetson平台和普通Ubuntu主机是两个世界遇到问题先想“NVIDIA官方有没有提供对应的JetPack方案”而不是直接去搜“Ubuntu安装NVIDIA驱动”方向错了就全是无用功。第二每次改动大配置之前先用nvpmodel -q确认当前电源模式。我曾经有好几次调试OpenPose时发现性能忽高忽低最后发现是电源模式被别的进程改了。把电源模式固定下来性能才有可复现性。第三如果你最终要在产品里上线不要停留在OpenPoseOpenPose更多是验证算法链路的好工具量产阶段建议换成TensorRT版本的适配模型或者直接剪枝量化体积和功耗表现会好很多。反正你在TX2上已经把数据链路、输入输出、坐标后处理这些打通了换模型只是换一个权重文件的事。我个人在实际操作中体会到折腾TX2的过程本质上是在训练一种“嵌入式视角”桌面GPU编程考虑的是怎样把算力吃满嵌入式平台考虑的是怎样用最小的资源把问题解决到可用水平。这种思维转变比跑通OpenPose本身值钱得多。希望这篇记录能帮你把前面最陡的一段山路先走平剩下的路你很快就能自己跑起来。
OpenPose在Jetson TX2上的部署实战：从环境配置到性能优化
把OpenPose这块CMU开源的姿态估计框架跑进NVIDIA Jetson TX2这块手掌大的板子里说难不难说简单也真不简单。OpenPose输入一张图就能把多个人体头、肩、肘、腕、膝这些关键点标出来背后的PAFPart Affinity Fields思路在计算机视觉圈子里相当有名。问题在于这套框架天生是为桌面级GPU设计的到了Jetson TX2这种嵌入式平台ARM CPU加Pascal架构小GPU性能、显存、功耗全都要重新算计。我在这块板子上断断续续折腾了半个多月刷机至少五次总算把它稳定跑了起来。这篇就把完整流程、关键编译参数、性能优化路线和踩过的坑都整理清楚给有同样需求的人一份能直接照着做的参考。无论你是做边缘端人体检测、智能安防还是想把视觉AI真正部署到设备端这篇文章应该都能帮你少走点弯路。1. 为什么非要在TX2上跑OpenPose很多人第一次听这个需求会觉得奇怪OpenPose在普通带NVIDIA显卡的台式机上装好驱动就能跑为什么非要往嵌入式板子上折腾这个问题的答案其实也是整个项目取舍的核心。1.1 OpenPose是什么解决了什么问题OpenPose的核心能力是单人或者多人的2D关键点检测。一张照片里好几个人站在一起它也能把每个人的四肢骨架分开标注这是早期很多姿态估计算法做不到的。它能做到这一点靠的是两路CNN分支并行输出一路预测每个关键点的置信图Confidence Map另一路预测关键点之间的亲和场PAF我的理解是它在学习“哪块骨头应该从哪里连到哪里”。PAF的出现是里程碑式的它让多人姿态估计不再需要先做人体检测再逐个人推理而是先出所有候选点再用亲和场把这些点连成正确的骨架整个流程端到端。这套模型的现实价值很直接。健身动作校正、老人跌倒检测、工人安全帽佩戴姿态分析、零售门店的顾客动线统计本质上都可以缩减成“先拿到骨架坐标再在坐标上做规则判断”。OpenPose把最难的视觉部分做完上层业务只需要处理一堆坐标点开发门槛一下子就降下来了。这也是为什么这么多年过去哪怕出了大量新模型OpenPose依旧被很多人拿来做项目原型。1.2 嵌入式选型为什么是Jetson TX2而不是其他平台选型这件事我和团队最初吵过一轮。候选平台有三个树莓派4B、Jetson TX2、桌面级先跑通再迁移。树莓派4B价格确实便宜但它的GPU没有统一内存计算生态跑OpenPose这种计算密集型的CNN基本只能看幻灯片一张图要跑几十秒完全不具备实时性。桌面级GPU效果最好但设备体积、功耗、散热摆在那里很多部署场景根本放不下一个带电源的塔式主机更别提车载、无人机、巡检机器人这种只能用电池供电的移动设备。Jetson TX2是中间态里最合适的那个。它的GPU是NVIDIA Pascal架构256个CUDA核心和桌面端的CUDA生态完全一致意味着OpenPose这类原本跑在桌面GPU上的代码可以比较顺畅地移植。整板加上散热模组功耗在7.5W到15W之间比桌面显卡动辄两三百瓦的功耗低了两个数量级。8GB的LPDDR4内存是统一内存架构CPU和GPU共享同一块内存省去了数据来回拷贝的带宽开销。另外TX2本身是模块化设计核心板加载板就能组成一台小电脑也可以直接嵌入到自己的PCB上这点对产品落地非常友好。考虑到我们要做的是人体姿态实时分析需要同时保证算力、体积和CUDA兼容性TX2在2024年之前一直是这个场景的常见选择之一。现在市面上虽然有Jetson Orin NX、Orin Nano这些算力更强的新品但在二手市场TX2价格被压得很低一块带底座的TX2可能只有几百块钱拿来做学习、做原型验证、跑通算法流程性价比依旧很能打。2. 环境搭建系统、驱动与依赖库一把梭在TX2上跑OpenPose最耗时间的不是编译OpenPose本身而是提前把系统环境调到省心状态。很多人在第一步刷系统的时候就踩坑后面全崩所以这里我把环境准备部分拆开慢慢讲。2.1 JetPack镜像选择与首次开机配置TX2不能像普通电脑那样随便装Ubuntu镜像它必须刷NVIDIA官方提供的JetPack系统包。JetPack里不仅包含Linux系统还预置了跟硬件深度适配的NVIDIA驱动、CUDA、cuDNN、TensorRT。这里我要特别强调一句Jetson平台不要自己手动去NVIDIA官网下载显卡驱动然后在Ubuntu里跑安装包那样极大概率出现热词里那个典型的报错“nvidia-smi has failed because it couldnt communicate with the nvidia driver”。因为TX2的驱动是跟内核模块绑定在一起由JetPack统一管理的手动装驱动会直接搞坏内核模块和用户态驱动的版本匹配关系最后只能重刷系统。我自己用的是SDK Manager刷机方式。准备一台装有Ubuntu 18.04或20.04的x86主机安装NVIDIA SDK Manager用Micro-USB线连接TX2的恢复模式并通电在SDK Manager里选择对应的JetPack版本和TX2目标设备它会自动完成系统烧录、驱动安装和CUDA部署。这里有个版本选择问题TX2官方最终支持的长期支持版本是JetPack 5.1.2对应Ubuntu 20.04、CUDA 11.4、cuDNN 8.4、TensorRT 8.5。老一点的JetPack 4.6.4对应Ubuntu 18.04和CUDA 10.2。我建议能上JetPack 5.1.2就尽量上高版本因为新版对Python 3.8的支持更好很多依赖安装起来更省事。刷完之后先用下面的命令验证环境是否正常nvcc -V nvidia-smi如果两个命令都能输出正常信息说明CUDA和驱动已经就位。接着还要做一件事——设置TX2的电源模式。TX2默认是MAX-N模式性能全开但功耗高也可以切换到MAX-Q或者5W模式。不同模式对AI推理帧率影响非常大这个在性能优化章节我再详细对比。我先建议直接用MAX-Nsudo nvpmodel -m 0想要开机自动生效再执行一次sudo nvpmodel -q2.2 OpenCV和其他依赖库的安装细节OpenPose代码里大量使用OpenCV做图像读取和显示而且对OpenCV接口有比较深度的依赖。在TX2上徒手从源码编译OpenCV是一个大坑——编译一两个小时、随时OOM、版本不匹配导致OpenPose找不到头文件这三件事我全经历过。后来我学乖了直接用JetPack自带的OpenCV不用额外折腾。JetPack 5.1.2自带OpenCV 4.5.4已经被NVIDIA针对Jetson平台优化过支持CUDA加速。确认一下版本在终端里执行python3 -c import cv2; print(cv2.__version__)如果提示没有安装可以装一个Python包sudo apt update sudo apt install python3-pip sudo pip3 install opencv-python-headless注意这里我装的是headless版本因为TX2很多时候是无人值守部署不需要OpenCV的GUI弹窗headless还能少依赖一堆X11库。如果非要可视化调试再装完整版也不迟。OpenPose源码里带了改进版的Caffe编译时会自动构建这个Caffe依赖protobuf、glog、gflags等库。JetPack 5.1.2系统里自带的protobuf版本是3.12如果后续编译OpenPose出现protobuf版本报错不要强求升级系统的protobuf非常容易搞坏系统组件。正确思路是用conda单独建一个Python环境或者通过pip在用户目录装指定版本。我自己的做法是直接用系统的protobuf去编译CaffeOpenPose自带的Caffe对protobuf版本要求没那么苛刻原生编译反而没出太大问题。需要用到的系统依赖直接一次性装齐sudo apt update sudo apt install -y build-essential cmake git libatlas-base-dev \ libprotobuf-dev protobuf-compiler libgoogle-glog-dev libgflags-dev \ libhdf5-dev libleveldb-dev libsnappy-dev liblmdb-dev \ libboost-all-dev libgphoto2-dev libeigen3-dev libhdf5-serial-dev装完这些依赖环境就算准备得七七八八了。3. 编译核心OpenPose源码构建的5个关键参数OpenPose官方仓库的新版本目前主要针对桌面环境维护在Jetson TX2上编译时不能直接无脑用默认参数有五六个关键点需要提前确认不然要么编不过要么编出来跑不动。3.1 获取源码与目录结构说明下载源码这一步很简单但有几个细节值得提一下。一个是要用递归克隆因为OpenPose仓库带了Caffe、3rdparty等子模块只克隆主仓库会导致后面编译时老是找不到依赖。命令如下git clone https://github.com/CMU-Perceptual-Computing-Lab/openpose.git --recursive如果你的网络在拉取子模块时不稳定可以单独初始化子模块cd openpose git submodule update --init --recursive源码目录不大核心的几个路径你要记清楚。src/openpose是框架核心源码src/caffe是被OpenPose魔改过的Caffe分支models存放所有要下载的模型权重build是我们编译的输出目录。里面的models/getModels.sh脚本是个隐藏关键它会把CMU原版的几个模型权重都下载下来但很多新手默认跳过这一步导致运行时疯狂报模型文件找不到。3.2 CMake参数详解与编译实操OpenPose使用CMake做构建配置在TX2上我个人建议直接在openpose根目录下新建一个build目录把全部CMake参数写在一个命令里。下面是我在多次刷机后最终稳定使用的完整配置你可以直接复制使用cd openpose mkdir build cd build cmake \ -D CMAKE_BUILD_TYPERelease \ -D BUILD_PYTHONON \ -D BUILD_EXAMPLESON \ -D BUILD_SHARED_LIBSOFF \ -D CMAKE_INSTALL_PREFIX/usr/local \ -D CUDA_TOOLKIT_ROOT_DIR/usr/local/cuda \ -D CUDA_ARCH-gencode archcompute_62,codesm_62 \ -D CUDNN_ROOT_DIR/usr/lib/aarch64-linux-gnu \ ..这一串参数里最核心的是CUDA_ARCH。很多人在TX2上编译失败就是因为它默认按桌面GPU去生成compute_75或者compute_86的机器码但TX2的GPU算力是6.2代码在运行时根本不能加载。写成archcompute_62,codesm_62是告诉编译器“我只针对TX2这块GPU生成二进制”生成的代码体积小、加载快、性能也更好。这个参数值不能被省略也不能简单写成compute_62我踩过这个坑编译能过但一运行就报“invalid device function”。BUILD_PYTHONON也很关键。如果你只跑命令行demo这里可以关掉编译时间能节省不少但如果你想在Python里调用OpenPose做业务集成就必须打开。JetPack 5.1.2对应的Python版本是3.8OpenPose官方对Python 3.8的支持已经没问题了。BUILD_SHARED_LIBSOFF是我个人的偏好直接用静态库可以把部署文件精简也避免在板子上出现符号引用找不到的问题。参数配好后接着编译。TX2的CPU性能有限如果直接make -j4大概率会在Caffe编译阶段因为内存爆掉直接死机或者退出。我强烈建议用-j2慢是慢点但胜在稳定编译一次全程三十分钟到一小时左右。命令如下make -j2编译完成后验证一下二进制文件是否存在ls build/examples/openpose/openpose.bin看到这个文件说明编译已经成功。3.3 模型下载与两种运行方式模型权重一定要在跑demo之前准备好。在openpose根目录执行cd models sudo chmod x getModels.sh ./getModels.sh这个脚本会下载三个主要模型BODY_25、COCO、MPI。其中BODY_25包含25个关键点在人体四肢、面部轮廓上的覆盖更全推荐使用。COCO模型包含18个关键点更接近老版COCO数据集的标注规范推理速度快一些。MPI模型比较老除非做对比实验否则基本用不上。脚本下载体积约500MB会有点慢建议用固定网络不要中间断掉。运行OpenPose有两种常见方式。第一种是直接用编译好的二进制这也是最快能看到效果的方式./build/examples/openpose/openpose.bin \ --model_pose BODY_25 \ --video examples/media/video.avi \ --write_json output_json/ \ --display 0因为TX2上我们往往没有显示器我习惯加上--display 0关闭GUI窗口同时用--write_json把每个人的关键点坐标以及置信度写到JSON文件里这样后续做业务逻辑就非常方便。第二种方式是用Python API。我给个最小示例适合要做二次开发的读者import sys sys.path.append(/path/to/openpose/build/python) from openpose import pyopenpose as op params { model_folder: /path/to/openpose/models/, model_pose: BODY_25, } opWrapper op.WrapperPython() opWrapper.configure(params) opWrapper.start() # 读图 import cv2 image cv2.imread(test.jpg) datum op.Datum() datum.cvInputData image opWrapper.emplaceAndPop([datum]) print(关键点坐标:, datum.poseKeypoints)这个API在桌面和TX2上的行为基本一致代码不需要大改就能迁移这也是Jetson平台做算法原型的一个优势。4. 性能实测从0.8 FPS到10 FPS的调优路线很多人费劲编译完OpenPose兴致勃勃跑第一张图发现帧率惨不忍睹就开始怀疑是不是板子性能不行。其实大部分情况下是默认配置根本不适应嵌入式平台稍微调一调性能可以翻好几倍。4.1 影响推理速度的4个直接因素第一个因素是模型选择。同样在TX2上COCO模型比BODY_25模型大约快20%-30%因为输出通道少、关键点数少。如果你只需要最基础的四肢关键点建议直接用COCO模型骨架质量差不了太多速度却更友好。第二个因素是输入分辨率。OpenPose默认把输入图按柄缩放为368x368或656x368这个选择直接影响CNN的计算量。分辨率降到240x240推理耗时大约只有368x368的40%。当然分辨率太低会导致小目标漏检需要在精度和速度中间找一个平衡点。第三个因素是可视化和预处理。默认情况下OpenPose不仅要做推理还要在内存中渲染骨架并输出画面这个渲染过程在嵌入式平台上也是要消耗CPU时间的。在部署场景如果不需要可视化记得关掉渲染和显示。第四个因素是硬件状态。TX2的电源模式、GPU频率、是否开TensorRT后端这几项对速度的影响比前面三个还大。默认MAX-N模式下GPU跑最高频率功耗约15W而5W模式下GPU频率严重受限同一张图推理时间可能拉两三倍。4.2 实测数据的对比与优化组合拳我自己在TX2上做过几组测试统一使用BODY_25模型、单张图片、MAX-N电源模式结果如下配置输入分辨率渲染开关平均耗时折算帧率默认配置368x368开约1100ms0.9 FPS关渲染368x368关约800ms1.25 FPS降到320x256320x256关大约500ms2 FPS降到240x240240x240关大约300ms3.3 FPSTensorRT FP16240x240240x240关大约150ms6-7 FPSTensorRT INT8240x240240x240关大约90ms10-11 FPS我的核心建议是分三步做优化。第一步关闭渲染和显示这个改动最小、收益最直接。第二步根据实际场景调整输入分辨率如果你的人体区域在画面里占比较大240x240已经足够。第三步如果还想要更快就去折腾TensorRT。在TX2上用TensorRT有个坑要提前说OpenPose新版本虽然提供了TensorRT支持但不同JetPack版本里TensorRT的层支持差别很大很多自定义层会报“op not supported”。我自己实测后认为最稳定的方案是直接使用OpenPose官方在CMake里带的USE_TENSORRTON选项编译后再在运行参数里加一个--trt。编译命令变为cmake \ -D CUDA_ARCH-gencode archcompute_62,codesm_62 \ -D USE_TENSORRTON \ ..运行命令加一行./build/examples/openpose/openpose.bin \ --model_pose COCO \ --image image.jpg \ --trt \ --write_json output/FP16转换一般不需要额外校准数据INT8则需要准备一组校准图片。至于具体回调到哪个FPS跟输入的图片还有环境温度都有关系我上面的表格是室内常温下的数据可以参考但不用死抠。5. 踩坑记录驱动异常、编译失败与内存爆掉这部分是整篇文章里我最想写的因为上面那些知识看文档都能查到但下面这些坑我基本都是靠拆机器和反复刷机换来的经验。5.1 系统与驱动层三板斧排查思路嵌入式平台最怕的就是开机后一切正常但一运行AI程序就报“nvidia-smi has failed because it couldnt communicate with the nvidia driver”。这句话我在Jetson社区看过无数遍在TX2上通常不是用户自己装驱动导致的而是内核模块和用户态驱动版本不匹配。常见的触发场景是SDK Manager刷机之后没有重启或者用apt upgrade升级了内核却忘了重新安装对应的NVIDIA驱动模块。第一板斧是重启。说出去很弱但这种问题很多时候重启就能解决因为驱动模块会在开机阶段重新加载。如果重启完还是报错第二板斧是用dmesg看内核日志重点找nvidia相关输出dmesg | grep -i nvidia如果看到“module verification failed”或者“unknown symbol”那基本可以断定是驱动模块匹配问题。第三板斧就是老老实实用SDK Manager重新刷机把系统恢复到干净状态。在Jetson平台上重刷系统成本不高与其在驱动层面花几个小时做外科手术不如直接重来。另外补充一个排查工具ls /usr/lib/aarch64-linux-gnu/libcuda*如果这个路径下找不到libcuda.so说明CUDA用户态库已经缺失直接刷机最高效。5.2 编译与运行期高频报错对照编译期间最常见的错误是Caffe编译时报“undefined reference to google::protobuf::...”。这个问题的本质是系统protobuf版本和OpenPose自带Caffe要求的版本不一致。我建议编译时不要强行指定高版本protobuf先确认系统版本protoc --version如果是3.12以上OpenPose自带的Caffe一般没问题如果是3.5以下的旧版本可以试着手动更新一下libprotobuf-dev。但要注意不要为了OpenPose去升级系统的protobuf到3.20以上那样很容易把系统中其他依赖老protobuf的软件搞崩溃。运行期报错最多的是“Check failed: status.ok() Failed to load: ../../models/pose/body_25/pose_iter_584000.caffemodel”。这个问题十有八九是因为你跳过了getModels.sh或者模型下载到一半断了。检查一下模型文件大小是否正常BODY_25的caffemodel应该在190MB左右如果只有几十KB那肯定是不完整。还有一个很典型的运行期报错是“bad allocation”或者直接进程被杀。TX2只有8GB内存CUDA和OpenCV同时跑起来内存压力很大。我的经验是编译时用-j2运行单线程推理必要时配置swap空间sudo fallocate -l 4G /var/swapfile sudo chmod 600 /var/swapfile sudo mkswap /var/swapfile sudo swapon /var/swapfile这样能极大缓解内存不足导致的随机崩溃。5.3 写给后来人的几条实在建议最后分享几条我在这个项目上沉淀下来的经验。第一Jetson平台和普通Ubuntu主机是两个世界遇到问题先想“NVIDIA官方有没有提供对应的JetPack方案”而不是直接去搜“Ubuntu安装NVIDIA驱动”方向错了就全是无用功。第二每次改动大配置之前先用nvpmodel -q确认当前电源模式。我曾经有好几次调试OpenPose时发现性能忽高忽低最后发现是电源模式被别的进程改了。把电源模式固定下来性能才有可复现性。第三如果你最终要在产品里上线不要停留在OpenPoseOpenPose更多是验证算法链路的好工具量产阶段建议换成TensorRT版本的适配模型或者直接剪枝量化体积和功耗表现会好很多。反正你在TX2上已经把数据链路、输入输出、坐标后处理这些打通了换模型只是换一个权重文件的事。我个人在实际操作中体会到折腾TX2的过程本质上是在训练一种“嵌入式视角”桌面GPU编程考虑的是怎样把算力吃满嵌入式平台考虑的是怎样用最小的资源把问题解决到可用水平。这种思维转变比跑通OpenPose本身值钱得多。希望这篇记录能帮你把前面最陡的一段山路先走平剩下的路你很快就能自己跑起来。
