Jetson AGX Thor + Orbbec 3D 相机：本地多模态机器人巡检系统开发实战

项目开发周期：2026 年 6 月 1 日至 2026 年 7 月 2 日。
项目设备：NVIDIA Jetson AGX Thor Developer Kit，外接 Orbbec Gemini 345Lg / RealSense D435i 3D 相机，预留 Airy LiDAR 数据通道。
项目代码位置：NVIDIA_Thor_Demos/thor_orbbec_3d_robot_demo。

这篇文章复盘一个运行在 Jetson AGX Thor 上的边缘 3D 机器人感知应用项目：一台 Thor 加一台 3D 相机，在本地完成 RGB 识别、深度/点云处理、占据栅格构建、风险判断、VLM 场景理解、RAG 规则检索、LLM 决策、TTS 播报和巡检报告生成。

我做这个项目的出发点很朴素：很多机器人方案在演示视频里看起来很炫，但一旦离开云端 API、离开台式机 GPU、离开提前录好的视频，就很难在现场稳定跑起来。真实展厅、工厂、仓库和实验室需要的是另一种能力：设备本地就能看见、理解、判断和记录，而且网络不稳定时也能继续工作。

一、项目整体介绍与落地场景

这个项目第一版的目标可以概括为一句话：

让机器人在 Jetson AGX Thor 上本地完成“看见环境、理解风险、查规则、做决策、说结果、留报告”的完整闭环。

下图是项目在 Jetson AGX Thor 真机服务上采集的 RGB-D 与点云数据。RGB 画面包含办公环境，因此发布前做了模糊脱敏；深度图和点云俯视图保留了空间结构，用来说明系统确实接入了 3D 传感器数据，而不是只做前端模拟。

Jetson Thor 上采集的脱敏 RGB-D 与点云俯视图

项目面向的场景是移动机器人、巡检机器人和工厂通道安全检测。典型任务是：机器人前方出现人员、箱子、工具车或杂物时，系统需要判断是否可以继续通行。如果只依赖 RGB 图像，机器人可能知道“画面里有一个人”，但不知道距离；如果只依赖深度或点云，机器人知道“前方 1.05 米有障碍”，但不知道障碍物是什么；如果只依赖规则脚本，又很难解释现场语义。

所以我把系统拆成三条线：

几何感知线：RGB-D 相机输出 RGB、Depth、IR 和点云，点云模块计算最近障碍物距离、地面/非地面点数量和通道占用情况。
语义理解线：YOLO 负责目标检测，VLM 负责理解画面语义，比如“人员位于前方约 2.4 米”“箱子占用通道右侧”。
决策解释线：RAG 从本地 SOP / 巡检规则中取回约束条件，LLM 根据检测结果、点云距离、VLM 描述和规则生成机器人动作建议。

最终输出不是一句空泛的“有风险”，而是一份结构化巡检报告：检测到什么目标、最近障碍物多远、风险等级是什么、为什么要停车、下一步动作是什么。

项目第一版支持传感器与模型的兜底模式，是为了保证没有相机、没有真实大模型、没有完整传感器链路时也能在离线环境跑通完整业务流程。但代码里已经预留了 RealSense、Orbbec SDK、YOLO/TensorRT、Qwen2.5-VL、NVlabs Eagle LocateAnything、Ollama/vLLM 和 TTS 后端的切换点。换句话说，它不是一个纯展示页面，而是一个可以逐步替换真实模块的边缘机器人感知系统骨架。

二、硬件、SDK、模型和工具选型

1. 硬件平台：为什么选 Jetson AGX Thor

我选择 Jetson AGX Thor，主要因为这个项目同时吃三类资源：

3D 传感器数据：RGB、Depth、IR、点云会持续刷新，对 I/O、CPU 和内存都有压力。
多模型推理：YOLO、VLM、LLM、TTS 可以串行跑，也可以逐步做并行优化。
本地服务化：FastAPI、WebSocket、前端可视化、报告生成和监控都在同一台设备上完成。

Thor 的优势不是单点跑一个模型，而是能把多模态机器人链路放在一台边缘设备里。相比把图像传到云端，Thor 本地处理可以减少网络依赖，也避免把工厂、实验室或仓库现场画面传出内网。对于机器人来说，低延迟和数据闭环比单纯的模型参数规模更重要。

项目中还保留了对 Jetson Orin 的经验复用。例如监控模块同时兼容 nvidia-smi、pynvml 和 Jetson 常见的 tegrastats 思路，方便后续把链路下放到 AGX Orin 或 Orin NX 上做裁剪版本。

2. 传感器和系统软件

传感器侧设计了三层兼容：

模块	作用	当前状态
RealSense D435i	RGB-D 相机输入	已实现服务封装，优先尝试启动
Orbbec Gemini 345Lg	目标 3D 相机	预留 `OrbbecCameraService` / SDK 适配接口
MockOrbbecCameraService	离线调试与流程验证	默认 fallback，保证无硬件可运行
Airy LiDAR	激光点云扩展	已预留点云和扇区分析接口

软件栈以 Python + FastAPI 为核心：

FastAPI：提供 Web UI、REST API、上传图片、巡检任务、健康检查和 WebSocket 事件流。
Pydantic：定义检测结果、点云统计、风险分析、VLM 输出、LLM 决策等结构化 schema。
NumPy / OpenCV：处理深度图、IR、点云可视化和安全区域热力图。
psutil / pynvml / nvidia-smi：采集 CPU、内存、GPU、功耗和温度指标。
Markdown 报告：每次巡检完成后自动生成可归档的 .md 报告。

3. AI 模型选型

当前版本默认使用兜底 AI 服务，原因是比赛文章强调的是完整开发流程和边缘系统架构，第一阶段我更看重链路可运行、数据结构稳定和模块边界清晰。真实模型接入点如下：

模块	默认实现	真实接入建议
目标检测	可替换检测服务	Ultralytics YOLO、TensorRT Engine、DeepStream
VLM	可切换视觉语言服务	Qwen2.5-VL、InternVL、NVlabs Eagle LocateAnything
RAG	MarkdownRAGService	FAISS、Chroma、本地 SOP 文档库
LLM 决策	可替换决策服务	Ollama、vLLM、OpenAI-compatible API
TTS	可替换语音服务	Piper、edge-tts、CosyVoice

我没有一开始就把所有模型都接成真实推理，是因为机器人系统最怕“模型能跑，但工程链路不稳”。先固定输入输出 schema，再逐步替换真实后端，可以避免前端、状态机、报告和决策层被模型输出格式反复牵着走。

三、完整开发流程与核心实现

1. 任务状态机

项目的主流程由 InspectionTaskRunner 驱动，每次巡检任务会经历以下阶段：

CAPTURE_SENSOR_FRAME
RGB_DETECTION
DEPTH_PROCESSING
POINTCLOUD_PROCESSING
OCCUPANCY_GRID_BUILDING
RISK_ANALYSIS
VLM_ANALYSIS
RAG_RETRIEVAL
LLM_DECISION
TTS_SPEAKING
REPORTING
DONE

这样做的好处是，每个阶段都有明确输入、输出和耗时记录。前端通过 WebSocket 订阅任务事件，可以看到任务从相机采集、YOLO 检测、点云处理一路推进到报告生成。开发调试时，哪个阶段慢、哪个阶段报错、哪个模块输出异常，都能马上定位。

2. 相机与输入源切换

机器人感知项目有个常见问题：开发时手边不一定有真实传感器。如果系统强依赖相机在线，很多功能就没法调。这个项目的输入源支持两种模式：

摄像头模式：使用 RealSense / Orbbec / 兜底相机服务的当前帧，保留 RGB、Depth、IR、PointCloud 流程。
图片模式：上传本地图片作为 RGB / VLM 输入，Depth、IR、PointCloud 继续由当前传感器或兜底数据补齐。

这让开发、测试和现场验证都更轻松。现场有相机时跑实时链路；没有相机时上传一张通道图片，也能完整验证检测、风险分析、RAG、LLM 和报告。

3. 点云统计与占据栅格

点云处理不追求复杂 SLAM，而是先解决机器人避障里最直接的问题：前方有没有障碍，最近障碍物多远，通道是否被占用。

系统会对点云做范围过滤和下采样，默认把点云压到 8000 个点以内，既能保留空间结构，又避免浏览器端渲染压力过大。随后计算：

点云总数和下采样数量
最近障碍物距离
地面点数量
非地面点数量
可通行区域和占用区域统计

一次测试报告中的结果如下：

指标	数值
点云数量	8500
下采样数量	8000
最近障碍物距离	1.05 m
障碍物点数量	2948
地面点数量	5552
Occupancy Grid occupied	35
Occupancy Grid free	803

这组数据已经足够支撑一个实际机器人判断：前方 2 米内存在障碍物，通道不宜直接通行。

为了便于公开分享，我把接口返回的点云数据单独渲染成俯视距离图。图中机器人位于底部，红色点表示近距离高关注区域，青绿色点表示更远处的空间结构。相比只展示 RGB 画面，点云俯视图更能说明 3D 感知模块在机器人避障里的作用。

RealSense 点云俯视距离图

4. 风险分析、RAG 和 LLM 决策

风险分析模块先根据硬规则给出初步判断。例如：

前方 2 米内有障碍物，应减速或停车。
人员进入前方 3 米安全范围，应停车等待。
箱子、工具或杂物占用通道，应标记为通道堵塞。
RGB 与点云冲突时，优先相信点云距离。

这些规则来自本地 Markdown SOP，通过 RAG 模块检索后交给 LLM。LLM 不直接“凭感觉”决策，而是收到结构化上下文：

用户指令：请定位 person 和 box 并判断能否通行。
YOLO 检测：person 置信度 0.91，距离约 2.4 m；box 置信度 0.88，距离约 1.3 m。
点云统计：最近障碍物约 1.05 m。
VLM 描述：前方通道内有人和箱子，箱子偏右，可能影响通行。
RAG 规则：人员进入 3 米范围应停车，2 米内障碍应减速或停车。

最终输出的决策是：

{
  "decision": "STOP_AND_WAIT",
  "speed_advice": "停车或低速等待",
  "path_advice": "当前不建议直接通行，可等待人员离开后从左侧绕行",
  "reasoning_summary": "点云显示最近障碍物约1.1米，RGB检测到人员约2.4米。根据规则，人员进入前方3米范围时应停车等待。",
  "final_message": "前方存在人员和障碍物，建议停车等待并重新规划路径。"
}

这个结果对机器人系统很重要。它既有动作建议，也有解释依据，方便工程师复盘，也方便后续接入 ROS2、Isaac Sim 或真实底盘控制。

四、开发难点、问题排查与解决方案

难点一：真实硬件不稳定时如何保证项目可运行

3D 相机、深度流、IR 流、点云和模型服务任何一个模块出问题，整条链路都可能断。我的解决办法是“真实服务优先，兜底服务保障流程”。启动时系统先尝试 RealSense，再尝试 Orbbec，失败后自动切到本地兜底相机服务。

这样做不是为了偷懒，而是为了把工程调试拆开：前端、状态机、报告、RAG 和决策可以独立验证；等相机 SDK 装好以后，只替换相机服务，不改上层逻辑。

难点二：多模态输出格式容易失控

YOLO、VLM、LLM 输出天然不稳定。如果直接把模型原始文本丢给前端，页面和报告很快会变成各种特殊情况的集合。项目里所有核心输出都用 Pydantic schema 约束，例如 Detection、PointCloudStats、RiskAnalysis、VLMSceneResult、RobotDecision。

后续接入真实 Qwen2.5-VL 或 vLLM 时，只需要把模型输出校验成统一 schema。校验失败就重试或降级，而不是让错误一路传到前端。

难点三：点云既要可用又要轻量

点云数据很容易变大。直接把完整点云通过接口返回给浏览器，会拖慢页面，也会增加 Jetson 的 CPU 压力。我采用了三步：

按距离过滤，只保留业务相关范围。
下采样到 8000 点以内。
前端只做轻量级渲染，真正判断在后端完成。

这样既能展示 3D 空间感，又不会让点云可视化压垮主流程。

难点四：机器人决策必须可解释

很多 AI 应用最后只输出一句话：“建议停车”。但机器人场景里，这不够。工程师和客户会追问：为什么停车？是因为人，还是箱子？距离多少？规则从哪里来？

所以项目把 RAG 规则、风险分析、VLM 场景描述、LLM reasoning summary 和最终动作全部写进报告。一次巡检结束后，报告里能看到完整证据链，而不是只看最终答案。

五、从 NVIDIA Vesta 看这个项目验证了什么

在项目开发过程中，我也重点关注了 NVIDIA Vesta 这类 embodied reasoning / generalist planner 的方向。Vesta 的核心思路不是让一个模型直接替代底层控制器，而是把定位、导航、具身推理、长程规划和记忆能力统一到一个高层机器人 planner 中。它观察当前环境，结合历史记忆和任务目标，输出下一步自然语言子任务，再交给底层 actor 或控制系统执行。

这篇文章并不声称复现了 Vesta 的论文结果。原因很直接：当前项目没有接入 Vesta 权重，也没有复现 R2R-CE、AgiBot 或真实双臂机器人任务评测。更准确地说，这个 Jetson Thor + RGB-D 机器人巡检项目验证的是 Vesta 所代表的一个工程方向：把空间感知、规则记忆、场景理解和动作规划收敛到一个本地高层 planner 接口。

从这个角度看，项目已经验证了三件事。

第一，系统验证了统一 planner 接口的工程可行性。YOLO 检测、点云距离、占据栅格、VLM 描述、RAG 规则和 LLM 决策并不是各自孤立展示，而是被整理成统一结构化上下文，最终输出 STOP_AND_WAIT、SLOW_DOWN、REROUTE 这类机器人动作建议。这个接口和 Vesta 的高层 planner 思路是接近的：planner 不直接控制电机，而是给出下一步可执行子任务或动作意图。

第二，项目验证了 3D spatial grounding 对机器人巡检的价值。纯 RGB VLM 只能说“画面里有人和箱子”，但 RGB-D / 点云可以进一步给出最近障碍物约 1.05 米、人员约 2.4 米、箱子约 1.3 米这类空间依据。对于机器人来说，能不能通行不是一个纯语义问题，而是语义和几何共同决定的问题。

第三，项目验证了本地规则记忆和可解释决策的重要性。Vesta 强调历史观察和已执行子任务对长程规划的作用；本项目当前先用 RAG 和结构化报告保存规则、风险依据和决策结果。下一步如果要更贴近 Vesta，可以增加连续巡检记忆：例如第一次看到箱子占用右侧通道，第二次画面里箱子被遮挡但点云仍显示右侧障碍，planner 仍能结合历史动作和当前 3D 观测建议停车或绕行。

因此，这个项目更像是一次边缘侧的 Vesta-style 架构验证，而不是 Vesta 模型复现。它证明了在 Jetson Thor 这样的边缘设备上，可以把 3D 感知、视觉语言理解、规则检索和动作决策先串成一个稳定闭环；等未来 Vesta 或同类 embodied planner 开放可部署权重后，可以把当前 LLM 决策层替换成更强的统一 planner。

六、项目效果、数据与后续优化

在兜底传感器 + 默认服务配置下，一次完整巡检可以在本地生成如下结果：

模块	输出
RGB 检测	person、box 两类目标
点云最近障碍物	1.05 m
风险等级	HIGH
是否需要停车	true
VLM 场景结论	通道内有人和箱子，可能影响通行
RAG 命中规则	2 米障碍减速/停车、3 米人员停车等待
LLM 决策	STOP_AND_WAIT
报告输出	自动生成 Markdown 巡检报告

部分阶段耗时也被记录到报告中。例如一次测试里，传感器帧采集约 4.26 ms，RGB 检测阶段约 201.24 ms。由于当前 YOLO 使用兜底检测服务，这个耗时主要体现链路调度和端到端流程；接入 TensorRT YOLO 后，下一步会重点测试真实检测 FPS、端到端延迟和功耗。

项目当前还有几个明确的优化方向：

接入真实 Orbbec SDK：完成 Gemini 345Lg 的 RGB、Depth、IR、PointCloud 实时流适配。
接入 TensorRT YOLO：把兜底检测替换为真实模型，并记录 FP16 / INT8 推理速度。
接入真实 VLM：优先测试 Qwen2.5-VL、InternVL 和 LocateAnything-3B 在 Thor 上的视觉定位能力。
接入本地 LLM：使用 Ollama 或 vLLM 运行 Qwen 系列模型，验证结构化 JSON 输出稳定性。
接入 ROS2 / Isaac：把 STOP_AND_WAIT、SLOW_DOWN、REROUTE 等动作映射到机器人控制接口。
做功耗与温度曲线：记录长时间运行下的 GPU 利用率、内存占用、功耗和温度。

总结

这次 Jetson AGX Thor + Orbbec 3D 机器人巡检系统开发给我最大的感受是：边缘 AI 项目的关键不只是“能不能跑一个模型”，而是能不能把传感器、模型、规则、决策、交互和报告稳定地串起来。

Thor 的价值也在这里。它让机器人系统不必把所有数据送上云端，不必依赖远程大模型服务，不必在网络波动时停摆。对于工厂、仓库、实验室和展厅，真正有用的是本地闭环：现场数据现场处理，风险现场判断，结果现场解释。

这个项目还在继续迭代。第一版先把工程骨架和闭环跑通，后面会逐步替换真实相机、真实检测模型、真实 VLM 和真实 LLM。等这些模块全部接上后，它会进一步沉淀为一套可以迁移到移动机器人、巡检机器人和工业安全检测终端上的边缘多模态机器人开发模板。