以“相机看到 AprilTag，底盘停到指定距离”为例，真正要接通的是时间戳、模型、规划、控制和急停，而不是一个孤立的大模型。NVIDIA 的 Cosmos、Isaac Sim、Isaac ROS、TensorRT 和 Jetson 分别覆盖数据、仿真、机器人计算图、推理和边缘算力；ROS 2、控制器与安全 I/O 决定这些组件在异常时怎样停下来。

采集或生成机器人数据→训练感知/决策模型→Isaac Sim 仿真验证→Jetson 边缘推理→ROS 2 与控制器安全执行
数据与模型传感器数据要带时间戳、置信度与失效状态，模型不应只输出动作。仿真与验证先在 Isaac Sim 或等价环境验证坐标、时延和失败路径，再接真实设备。推理与部署TensorRT 与 Jetson 负责目标硬件上的吞吐、内存和 P99 延迟。任务与通信ROS 2 节点要约定消息时效、取消、超时和降级语义。实时执行MCU、PLC 或实时控制线程独立处理限位、看门狗和急停。安全闭环模型不可用、通信中断或约束失效时，系统必须进入确定的安全状态。

三层职责，先把线画出来

感知与认知层处理图像、点云、语音和语言指令，输出目标、位姿、地图或任务意图。这个层可以使用 GPU 和大模型，允许有几十到几百毫秒的延迟，但必须带时间戳、置信度和失效信号。

决策与任务层把“去拿桌上的杯子”转成有限状态机、行为树或 ROS 2 Action。它应明确任务前置条件，例如地图可用、机械臂已回零、抓取区没有人，并能随时取消或超时。

实时执行层负责电机闭环、限位、急停和通信看门狗。它不等待语言模型回复，也不把障碍物距离交给模型自由解释。工业机器人常让 MCU、PLC 或经过实时化的控制线程承担这一层；Jetson 更适合运行前两层。

接口里要写哪些失效

一个能落地的节点接口，不只有消息类型，还应声明四件事：输入是否允许过期、最长可接受处理时间、输出的坐标系/单位，以及失败时的动作。例如视觉检测节点若在 200 ms 内没有新帧，就发布 valid=false；导航节点看到该标志后停止更新目标；底层控制器若持续收不到新速度指令，则进入安全减速或刹停。

1
2
3
4
5
camera_frame(stamp, image)
    -> detector(stamp, objects, confidence, valid)
    -> task_guard(max_age=200 ms, min_confidence=0.75)
    -> motion_action(goal, timeout, cancel)
    -> controller(watchdog, velocity_limit, e_stop)

这比“模型输出一个动作就执行”多了几层检查，却是机器人在昏暗、遮挡、网络抖动和软件重启时仍可控的原因。

从一个小闭环开始

建议先选一个很窄的闭环，例如“相机识别 AprilTag 后让机器人底盘停在指定距离”。先在 Isaac Sim 或 Gazebo 验证坐标变换、超时与取消路径，再把感知节点迁到 Jetson。最后才替换为检测模型、Visual SLAM 或 VLA 模型。每次只替换一层，才能知道延迟、漂移或失败是来自模型、ROS 2 通信还是执行器。

一个实际的验收表至少应包含：端到端图像年龄、推理 P99 延迟、Action 取消时间、控制指令超时行为、急停独立性，以及无 GPU/无相机/模型异常退出时的降级路径。模型置信度不足、通信超时或控制约束不满足时，应由确定性运行时降级或停车，而不是继续猜测。

参考：NVIDIA Robotics · ROS 2 Concepts

证据边界：本文是系统分层和验收方法的技术整理，没有给出某套 NVIDIA 硬件、模型或机器人平台的实际成功率。具体延迟、温度和急停行为必须通过目标设备的录包与故障注入确认。