同一块 Jetson 上，相机、TensorRT、录包和 ROS 2 都在正常工作，电机控制却偶尔晚一个周期。通常不是 GPU “算不过来”，而是 CPU 回调、内存带宽、温度降频和队列一起把实时路径拖慢。JetPack 把 Linux for Tegra、CUDA、TensorRT 和多媒体组件放在一起，部署时仍要把感知与控制的职责分开。

选择 JetPack 与功耗模式→部署模型和 ROS 2 节点→测量 CPU/GPU/内存负载→分离推理与实时控制→在温度稳定后复测长尾
资源图Jetson 是感知和任务平台，实时控制与安全链路应有更确定的执行边界。
相机与多媒体采集、颜色转换、编码和解码会占用专用引擎与内存带宽。GPU 推理TensorRT、CUDA stream 和显存使用影响模型吞吐与尾延迟。CPU 与 DDSROS 2 回调、序列化、规划和驱动仍会争抢 ARM CPU。共享内存多路相机和大模型常先受带宽与队列限制，而不是 GPU 算力。MCU/RT 控制电流、速度、限位和 watchdog 放在可预测、可独立失效的链路。安全停止急停和驱动抑制不依赖 GPU、ROS 2 或普通进程调度。

先看谁在抢资源

推理不只占 GPU。摄像头采集和图像颜色转换可能使用 ISP 或 VIC，视频解码会使用专用引擎，TensorRT 占 GPU 和显存带宽，ROS 2 节点、DDS 和驱动则会占用 CPU。多路相机加上大模型时，瓶颈往往从 GPU 算力变成内存带宽、CPU 回调排队或散热引起的降频。

因此应同时观察以下维度，而不是只看 FPS：

  • 模型侧：每帧推理延迟、GPU 利用率、显存占用、输入队列长度。
  • 系统侧：CPU 核心利用率、RAM/Swap、温度、频率变化和磁盘 I/O。
  • 机器人侧：图像从采集到被控制器使用的年龄、丢帧率、控制指令间隔。

Jetson 系统通常可用下面的命令进行初步观测。实际字段会随型号和 JetPack 版本变化，但它们足以帮助你判断是“模型慢”还是“整机正在喘不过气”。

1
2
3
sudo nvpmodel -q          # 查看当前功耗/性能模式
tegrastats                # 连续观察 CPU、GPU、内存、温度与频率
sudo jetson_clocks --show # 查看可锁定的时钟状态

jetson_clocks 很适合做可重复的性能测试，但在产品上长期强制最高频率会带来功耗、温升和续航成本。正确顺序是先测清热稳定后的长尾，再决定是否改变功耗模式、风扇策略或模型规模。

让 Jetson 和控制器各管一段

常见结构是 Jetson 运行相机、感知、地图、规划与 ROS 2 Action；一个 MCU、专用驱动器或独立实时线程负责编码器读取、电流环、速度环、限位与急停。两者之间只交换有限的、高层的命令和反馈，例如 cmd_vel、目标轨迹、状态字与故障码。

1
2
3
Jetson: camera -> TensorRT -> perception -> planner -> bounded velocity command
MCU/RT controller: watchdog -> limit check -> motor loop -> encoder feedback
Safety path: emergency stop -> power/driver inhibit, independent of GPU process

不要让推理进程直接写 PWM，也不要把急停实现成一个普通 ROS topic。前者把不确定的 GPU 负载带进控制环，后者会在网络、进程或 DDS 出问题时失效。

部署前要主动制造压力

  1. 固定 JetPack、CUDA、TensorRT 和模型版本，记录设备型号及功耗模式。
  2. 先跑单相机、单模型的冷启动与热稳定测试，再逐个加入相机、规划和录包负载。
  3. 用 tegrastats 与 ROS 2 时间戳一起记录，观察 P95/P99，而不是只看平均 FPS。
  4. 施加内存压力、拔插相机、降低照度、制造模型超时，验证控制器是否按预期降级。

这些情况都跑过后，才知道这套 Jetson 配置在机器人上遇到压力时会怎样反应。

参考：NVIDIA Jetson Documentation · Jetson Linux Developer Guide

证据边界：命令和职责划分适用于排查与部署设计，不代表所有 Jetson 型号、JetPack 版本或散热条件都会得到相同延迟。本文没有给出功耗模式下的具体 FPS、温度或 P99 数值。