Part 2: Hardware · The robot's body

Chapter 6

计算平台 - 机器人的“电脑”

上一章说到，代码指令和执行器的实际运动之间永远存在差距。但在执行器动作之前，还有一个更基本的问题：这些代码跑在哪儿？

想象你在玩一个实时对战游戏。你的操作延迟如果是 20 毫秒，完全没感觉；如果是 200 毫秒，开始觉得“黏”；如果是 2 秒 - 你的角色已经被打死了。

机器人面临的是同一个问题，但后果更严重。一台移动机器人以 1 m/s 的速度行走，如果感知到前方有障碍物后需要 500 毫秒才能做出决策，它已经又走了 50 厘米。50 厘米足以让它撞上墙壁、撞倒货架、甚至撞到人。在机器人的世界里，延迟不是体验问题，是安全问题。

这就是为什么机器人不能简单地把数据发到云端、等云端算完再发回来 - 它需要一台自己随身携带的“电脑”，在本地完成最关键的计算。这台电脑就是机器人的计算平台。

为什么不能用你的 MacBook

这个问题新手经常问。MacBook Pro 的 M4 芯片性能很强，跑 PyTorch 推理也不慢，为什么不能直接塞进机器人里？

三个硬约束：

功耗。 你的 MacBook Pro 在跑大模型推理时功耗大约 30-40 瓦，加上屏幕、SSD、散热风扇，整机功耗轻松到 60-80 瓦。这对一台插着电源线的笔记本来说不算什么，但机器人靠电池活着。一台典型的移动机器人电池容量在 500-1000 Wh 左右，如果计算平台一个人就吃掉 60 瓦，那它占了整个电力预算的很大一块 - 还没算电机、传感器和通信模块的用电。Jetson Orin Nano 跑满 AI 推理的功耗大约 7-25 瓦，这是一个数量级的差距。

尺寸和散热。 MacBook Pro 的主板有一个精密的散热系统，加上铝制机身作为散热面积。把它拆出来塞进一台人形机器人的躯干里？没有位置。机器人内部的空间被电池、电机驱动板、传感器接口板、线缆占得满满当当。计算平台通常只能分到一个手掌大小的位置，而且散热条件远比笔记本恶劣 - 旁边可能就是发热的电机驱动器。Jetson 模块的尺寸大概是一张信用卡大小（Orin Nano 是 69.6 mm x 45 mm），专门为嵌入式场景设计。

接口和实时性。 MacBook 的接口是给人用的 - USB-C、HDMI、WiFi。机器人的计算平台需要直接对接传感器和执行器：多路 MIPI CSI 相机接口、CAN 总线（和电机驱动器通信的工业协议）、GPIO（通用输入输出引脚，用来触发和读取简单信号）、多路以太网。更关键的是，机器人需要确定性的实时响应 - 不是“平均 10 毫秒处理完”，而是“保证每次都在 10 毫秒内处理完”。macOS 不是实时操作系统，它可能在任何时候因为后台任务暂停你的程序几十毫秒。Jetson 跑的是 Linux，配合 PREEMPT_RT 内核补丁可以提供更好的实时性保证。

所以选择不是“Jetson 比 MacBook 更强” - 恰恰相反，论绝对算力 MacBook 可能更强。选择是“Jetson 是为机器人这个约束环境专门设计的”。就像你不会开一辆跑车去工地搬砖，不是跑车不好，是场景不对。

NVIDIA Jetson 系列全解析

第 3 章的玩家地图里已经列过 Jetson 的基本参数。这里往深挖一层 - 不只是“有几个型号”，而是“什么场景用哪个，为什么”。

产品线一览

型号	AI 算力（INT8）	功耗范围	GPU 架构	内存	典型定位
Orin Nano	40-67 TOPS	7-25W	Ampere	4-8 GB	入门/单任务
Orin NX	70-100 TOPS	10-40W	Ampere	8-16 GB	开发主力
AGX Orin	200-275 TOPS	15-60W	Ampere	32-64 GB	旗舰/复杂场景
AGX Thor	~2000 TOPS（FP4）	40-130W	Blackwell	128 GB	下一代/人形机器人

几个关键点：

Orin Nano 是“够用就好”的选择。40-67 TOPS 足够跑一个 YOLO 检测模型做实时目标识别，或者一个轻量级的深度估计模型。如果你的机器人只需要做一件感知任务 - 比如一台只做导航避障的清扫机器人 - Orin Nano 绑绑有余。价格也最友好，开发者套件几百美元就能入手。

Orin NX 是大部分机器人项目的主力选择。70-100 TOPS 意味着你可以同时跑视觉 SLAM 和目标检测，或者一个检测模型加一个深度估计模型。16 GB 内存版本能加载更大的模型。多数商用移动机器人 - 送餐机器人、仓储 AGV、巡检机器人 - 用的是 Orin NX 这个档次。

AGX Orin 是当你发现 Orin NX 不够用时的升级路径。275 TOPS 加上 64 GB 内存，可以同时跑 3-4 个感知模型外加导航和规划的全套算法。人形机器人、复杂操作场景（比如需要同时做物体检测、位姿估计、场景分割的拣货机器人）通常需要这个级别。

AGX Thor 是 2025 年发布的新一代旗舰，基于 Blackwell GPU 架构，AI 算力跳到了约 2000 TOPS（FP4 精度）。这是 AGX Orin 的 7 倍多。它瞄准的是需要在机器人本地跑 Foundation Model 的场景 - 比如 VLA（Vision-Language-Action）模型做端到端的感知-决策-动作。128 GB 内存意味着可以加载相当大的模型。不过 40-130W 的功耗范围也说明，它更适合有稳定供电的场景（比如人形机器人有较大的电池），而不是小型移动机器人。

怎么选？

一个实用的决策框架：

列出你需要同时跑的所有算法 - 感知有几个模型？导航用什么方案？有没有 LLM/VLA 的需求？
估算总算力需求 - 每个模型在 TensorRT 优化后需要多少 TOPS 才能达到目标帧率
加 30-50% 余量 - 实际部署总是比预估多吃资源，你还需要留空间给 ROS 2 节点、系统开销、日志记录
检查内存 - 所有模型同时加载到显存里，够不够？这一条经常被忽略，然后部署时才发现 OOM（Out of Memory）

大部分团队的路径是：先用 Orin NX 开发和验证，确认算力不够再升级到 AGX Orin。 因为 Jetson 全系列跑同一套软件栈（JetPack SDK），迁移成本很低 - 代码基本不用改，重新编译一下就行。

TOPS 到底是什么意思

TOPS = Tera Operations Per Second，每秒万亿次运算。它是衡量 AI 推理算力的常用单位。

但这个数字需要带着精度标注一起看。同样写“100 TOPS”，在 INT8（8位整数）精度下和在 FP16（16位浮点）精度下意味着完全不同的东西。INT8 运算更简单，单位时间能做更多次 - 所以 INT8 TOPS 数字通常是 FP16 的两倍。AGX Thor 标称的 2000 TOPS 是 FP4 精度的数字，换算到 FP8 大约是 1035 TOPS。

对开发者来说，TOPS 是一个粗略的比较尺度，不是精确的性能指标。 实际推理速度取决于很多因素：模型架构（CNN 和 Transformer 对硬件的利用率不同）、batch size、内存带宽是否成为瓶颈、TensorRT 优化的程度。

一个更实用的衡量方式是直接跑 benchmark：用 TensorRT 把你的模型优化后，在目标硬件上实测推理延迟和吞吐量。NVIDIA 提供了 trtexec 工具专门干这件事。不要只看 TOPS 选型，一定要跑实测。 我见过有团队根据 TOPS 数字选了 Orin Nano，结果发现他们的模型因为内存带宽瓶颈根本跑不到理论峰值的一半。

GPU 在机器人上干什么

如果你的 AI 背景来自训练模型 - 在 A100 上跑几天训一个大模型 - 那你对 GPU 的认知可能需要调整一下。机器人上的 GPU 不是用来训练的，是用来推理的。

训练是“给几百万张图片，花几天时间学会识别物体”。这需要巨大的算力和内存，通常在数据中心的 A100/H100 上完成。

推理是“给一张图片，在 30 毫秒内告诉我图里有什么”。这需要的算力小得多，但对延迟的要求极其严格。机器人的感知系统每一帧都需要推理 - 如果相机 30fps，那推理延迟必须小于 33 毫秒才能不掉帧。

Jetson 上的 GPU 被优化来高效地做推理。核心工具链是 TensorRT - NVIDIA 的推理优化引擎。它拿到你的 PyTorch/ONNX 模型，做一系列优化：层融合（把多个小操作合并成一个大操作减少内存读写）、精度降低（从 FP32 降到 FP16 或 INT8，牺牲微小的精度换取 2-4 倍的速度提升）、针对具体 GPU 架构的 kernel 优化。

一个典型的例子：一个 YOLOv8-S 模型在 PyTorch 里用 FP32 在 Orin NX 上跑，推理一张图大约 30-40 毫秒。经过 TensorRT 优化到 FP16，降到 10-15 毫秒。进一步量化到 INT8，可以到 5-8 毫秒。同一块硬件、同一个模型，优化前后差 4-5 倍。 这就是为什么“会不会用 TensorRT”往往比“买哪个档次的 Jetson”更重要。

除了跑感知模型，GPU 在机器人上还干这些事：

点云处理：CUDA 加速的点云滤波、配准、分割
SLAM 前端：特征提取和匹配可以放到 GPU 上加速
路径规划中的碰撞检测：大量的几何计算很适合 GPU 并行

NVIDIA 的 Isaac ROS 包就是干这个的 - 把 ROS 2 常用的感知和导航算法用 CUDA 重写了一遍，专为 Jetson 优化。比如 Isaac ROS Visual SLAM、Isaac ROS Object Detection，它们提供和标准 ROS 2 节点一样的接口，但底层用 GPU 加速，性能提升明显。

边缘计算 vs 云计算

“计算”可以发生在两个地方：机器人自身携带的计算平台（边缘端），或者远程的云服务器。怎么分配？

关键原则：延迟敏感的决策必须在边缘端完成。

什么是延迟敏感的？所有和“不撞东西”、“不掉东西”、“不伤人”相关的决策。具体来说：

避障和导航：必须在边缘。以 1 m/s 移动为例，如果把传感器数据发到云端、云端处理、发回指令，即使网络延迟只有 100 毫秒，机器人已经又走了 10 厘米。如果是 WiFi 偶尔抖动到 500 毫秒 - 你的机器人已经撞上去了。
实时感知：必须在边缘。相机每秒产生 30 帧图像，每帧几百 KB 到几 MB。把这些数据全部上传到云端不现实，带宽扛不住，延迟也太高。
运动控制：必须在边缘。关节伺服控制的频率通常在 100Hz-1000Hz，也就是每 1-10 毫秒就需要计算一次控制信号。网络延迟在这个尺度下完全不可接受。

什么可以放到云端？

高层任务规划：比如“接下来去哪个货架拣货”这种决策，偶尔延迟几百毫秒甚至几秒也没关系
大模型推理：如果你要用 LLM 做自然语言交互或复杂推理，本地 Jetson 可能跑不动太大的模型，可以发到云端。（AGX Thor 的出现正在改变这个局面 - 128GB 内存可以在本地加载不少大模型）
数据回传和分析：运行日志、传感器录像发回云端做离线分析和模型改进
地图更新和共享：多台机器人可以把各自建的地图上传到云端合并，然后下发给其他机器人

实际架构通常是**“边缘为主、云端为辅”**：所有实时链路（感知 → 决策 → 控制）在本地闭环，非实时的任务调度和数据分析走云端。两者之间通过 API 或消息队列通信。

一个真实的踩坑场景

有团队做过这样的架构：把物体检测模型放在云端的 GPU 服务器上，机器人本地只做基础的避障。理由是“云端 GPU 更强，检测精度更高”。

在实验室里一切正常 - WiFi 网络稳定，延迟 50 毫秒以内，检测结果回来得很快。

部署到客户的仓库后，问题来了。仓库的 WiFi 信号被金属货架严重干扰，延迟从 50 毫秒跳到了 2-3 秒，偶尔还会断连。结果就是：机器人“看”到一个物体时，它实际上已经路过了那个物体 2 秒前的位置。更糟糕的是，断连期间机器人完全“瞎了” - 本地没有检测能力，只能急停等网络恢复。

最后的解决方案：在 Orin NX 上部署一个轻量级的检测模型做本地实时检测（保证“不瞎”），云端的高精度模型只用于非实时的精细识别（比如读商品条形码）。永远不要让机器人的安全依赖于网络连接。

JetPack 和软件生态

硬件只是一半，跑在上面的软件栈同样重要。

所有 Jetson 都运行 JetPack SDK - 这是 NVIDIA 为 Jetson 定制的完整软件包，基于 Ubuntu Linux。它包含：

L4T（Linux for Tegra）：定制的 Linux 系统，包含针对 Jetson 硬件的内核驱动
CUDA：GPU 通用计算框架，你训练模型时用的那个 CUDA，在 Jetson 上也是它
TensorRT：推理优化引擎，上面详细讲过了
cuDNN：深度学习加速库
VPI（Vision Programming Interface）：GPU 加速的计算机视觉基础操作 - 缩放、滤波、特征检测等
Multimedia API：硬件编解码器接口，处理视频流用

如果你之前在 x86 的 NVIDIA GPU 上开发过，Jetson 上的体验出奇地相似。CUDA 代码基本不用改（注意 Jetson 用的是 ARM 架构，少数依赖 x86 特有指令集的库需要替换），PyTorch 有 Jetson 专用的构建版本，TensorRT 的 API 完全一致。主要区别就是算力更有限，需要更在意优化。

对开发者日常影响最大的一个细节：JetPack 的版本和 ROS 2 的版本绑定关系。 JetPack 5.x 基于 Ubuntu 20.04，对应 ROS 2 Foxy/Humble；JetPack 6.x 基于 Ubuntu 22.04，对应 ROS 2 Humble/Iron/Jazzy。如果你用的 ROS 2 包需要特定版本的 Ubuntu，而那个版本的 JetPack 还没发布 - 恭喜你，你即将进入“Docker 容器套娃”的快乐世界。这也是为什么 Docker 在机器人开发中几乎是标配，后面 DevOps 那一章会详细讲。

开发者日常在调什么

计算平台层面的工程工作，主要集中在几个方面：

功耗模式切换。 Jetson 支持多种功耗模式 - 比如 AGX Orin 可以在 15W、30W、50W 和 MAXN（不限功耗追求最大性能）之间切换。开发阶段通常用 MAXN 方便调试，部署时根据电池续航需求降到合适的档位。用 nvpmodel 命令切换，用 jetson_stats（社区开发的 jtop 工具）实时监控 CPU/GPU 频率、温度、功耗。

模型优化。 把训练好的模型转换成 TensorRT 引擎，调整精度（FP16/INT8），profiling 找瓶颈。这是在 Jetson 上跑 AI 最花时间的环节。INT8 量化需要一个校准数据集（calibration dataset），如果校准数据和实际部署数据分布差太远，量化后精度会明显下降。

散热管理。 Jetson 在持续高负载下会热节流（thermal throttling） - GPU/CPU 自动降频来控制温度。在封闭机器人外壳内，散热条件比开放的开发者套件差很多。有团队在实验室跑得好好的算法，装到机器人里跑半小时后帧率从 30fps 降到 15fps - 就是因为热节流了。解决方案通常是加散热片、导热垫、甚至小风扇，或者优化算法降低持续负载。

多进程资源分配。 一台机器人上同时跑十几个 ROS 2 节点：相机驱动、点云处理、目标检测、SLAM、导航规划、控制器、行为树... 它们都在争 CPU 和 GPU 资源。谁优先？用 Linux 的 nice 和 cgroup 做 CPU 调度，用 CUDA MPS（Multi-Process Service）让多个进程共享 GPU。这块没有银弹，基本就是实测、调参、再实测。

计算平台是机器人软硬件栈的交汇点 - 它的能力上限决定了你的算法能跑多复杂，它的功耗下限决定了你的机器人能跑多久。选对硬件很重要，但更重要的是把软件优化到配得上这块硬件。很多时候，一个经过精心优化的模型在 Orin NX 上跑出的效果，比一个没怎么优化的模型在 AGX Orin 上跑的还好。