上篇聊了Jetson AGX Orin的选型理由和基础环境很多朋友留言问得最多的其实是同一个问题板子到了、系统刷好了然后呢这篇我把从一块Jetson AGX Orin到一臺能感知、能决策、能动起来的AGI机器人原型背后那套完整技术栈串一遍。从底层系统配置、ROS2通信骨架到SLAM建图导航再到端侧部署大模型做多模态感知最后落到运动控制和执行器思路和踩坑都会讲。适合刚入手Jetson系列、想往具身智能方向走但还没完全打通全流程的朋友参考。1. 为什么是Jetson AGX Orin一块板子背后的取舍逻辑AGI机器人听起来很遥远但落到硬件选型上核心指标无非三件事算力够不够跑感知模型、接口全不全接得齐传感器和执行器、功耗能不能被机器人本体接受。1.1 算力账从TOPS数字到实际能跑的模型Jetson AGX Orin的标称算力是275 TOPS。这个数字很多人看个热闹我帮大家拆一下实际能干什么。TOPS是INT8精度的理论峰值真实部署时要用TensorRT做模型优化跑FP16或者INT8量化。以我实测的数据YOLOv8s目标检测模型输入分辨率640x640TensorRT优化后跑FP16在Orin上能到接近200 FPS如果跑的是视觉语言模型如CLIP或者轻量VLM推理延迟大概在几十到几百毫秒级别。这意味着单块Orin足够同时跑一路视觉SLAM、一个目标检测模型、一个大语言模型做决策再加底盘控制不需要外挂显卡。对比上一代XavierOrin的CPU升级到12核Arm Cortex-A78AE这对机器人场景特别关键。机器人控制逻辑、ROS2中间件、运动学解算都是CPU密集型的GPU再强CPU跟不上一样卡。实测在Orin上同时跑导航栈和检测推理CPU占用控制在60%左右余量充足。1.2 和树莓派、x86工控机、其他加速卡怎么选很多新手纠结要不要先用树莓派练手。我的看法是如果目标就是做AGI机器人直接上Jetson系列别绕路。树莓派5的算力大约只有0.1 TOPS级别跑个yolov5n都够呛更不用说跑Transformer模型做决策。当然树莓派成本低、生态好适合学基础GPIO控制和简单避障。但如果你要做的机器人需要视觉理解、语义导航、大模型决策这些能力树莓派算力就是硬瓶颈到最后还得换平台中间写的ROS2代码虽然能迁移但硬件适配和调试时间全部浪费。x86工控机加独立显卡的方案算力最强但功耗和体积压不住机器人这个场景。AGV小车或者复合机器人一般要求整机功耗控制在几十瓦这个量级一张RTX 4060显卡功耗就115瓦了加上CPU、主板整机轻松破200瓦。AGX Orin的模块功耗在15瓦到60瓦之间可调配合电池供电能支撑几个小时的连续作业。1.3 这台配置对应什么形态的机器人按照AGX Orin的接口和算力特征比较合适的机器人形态大概三类一是移动底盘加机械臂的复合机器人。底盘负责导航机械臂负责操作Orin把所有计算扛下来。我见过最多的也是这种形态结合大模型做视觉抓取和语义导航。二是四足机器人。四足对运动控制的实时性要求极高Orin的实时性能和GPIO接口刚好够用。而且四足的负载能力通常10公斤左右正好能背一块Orin和传感器套件。三是VDA5050体系下的AGV调度节点。Orin作为车载计算单元跑导航、调度客户端和任务管理算力富余还可以加视觉避障。如果后面要对接工厂的中央调度系统VDA5050是不错的参考规范。2. 软件技术栈从底层系统到ROS2的完整骨架硬件是骨架软件是神经系统。AGI机器人的软件栈比我接触过的任何嵌入式项目都要复杂这节从底往上拆。2.1 JetPack版本与系统镜像选择Jetson平台的操作系统镜像叫JetPack里面有Ubuntu、CUDA、cuDNN、TensorRT、OpenCV这些预编译好的组件。选JetPack版本有一个原则不是越新越好而是看你的依赖生态跟不跟得上。我目前用的是JetPack 5.1.2配套Ubuntu 20.04和ROS2 Foxy。Jetson平台刷系统的思路是因为板卡架构是ARM很多开源库不会直接给Jetson发布二进制包但JetPack用SDK Manager管理会解决大部分依赖问题。如果上最新的JetPack 6.xUbuntu升级到22.04系统更新但一些底层库比如旧版TensorRT和自定义算子可能不兼容而且ROS2要切到Humble。建议新项目直接用新版但迁移老项目前先确认依赖包全部支持不然会花大量时间重新编译。2.2 容器化开发环境避免依赖地狱AGI机器人涉及Python、C、CUDA、ROS2、深度学习框架这堆依赖混在宿主机上早晚出问题。我在Jetson上强烈推荐用容器方案把开发环境、运行环境和系统镜像隔离。这里的关键是NVIDIA官方提供了Jetson容器的运行时支持JetPack自带Containerd和NVIDIA Container Toolkit可以直接跑带GPU加速的Docker容器。我自己的方案是写一套Dockerfile基于nvidia/cuda镜像装好Python依赖、ROS2和TensorRT然后挂载到宿主机上使用。Jetson容器有几个需要注意的点容器内使用CUDA需要宿主机安装NVIDIA Container Toolkit且容器启动时加--runtimenvidia参数。Docker默认的存储驱动在Jetson上性能一般建议把Docker根目录放到SSD上别放eMMC。容器内访问USB摄像头、串口这类设备启动时用--device/dev/ttyUSB0:/dev/ttyUSB0或者--privileged挂载设备节点。2.3 ROS2分布式通信AGI机器人通常会拆成传感器、感知、决策、运动控制、机械臂控制等模块这些模块之间的通信靠ROS2。ROS2基于DDS协议它的核心优势是节点分布式部署、实时性更好、支持QoS策略。ROS2的节点设计有个经验一个功能一个节点不要把所有逻辑塞进一个大节点。比如视觉检测一个节点SLAM一个节点导航一个节点大模型决策一个节点。每个节点独立编译、独立调试出问题时重启单个节点就行而不需要重启整个机器人程序。QoS配置也要注意。激光雷达点云和相机图像这种高频大流量数据用Reliable传输会导致延迟增加用Best Effort模式则更快。两者对丢包的容忍度不同。我一般做法是传感器数据用Best Effort加深度传感器协处理器控制指令用Reliable保证控制命令不丢失。2.4 数据接入摄像头、激光雷达和IMU机器人感知的第一环是数据接入。AGX Orin支持最多16路MIPI CSI输入也支持USB摄像头。我实际用的组合是Intel RealSense D435i做视觉和深度感知一个2D激光雷达做导航加上IMU模块做姿态估计。接入这些传感器最稳妥的办法是通过ROS2驱动包。RealSense和激光雷达都有现成的驱动IMU如果选的是市面上常见型号基本也能找到对应的ROS2包。这块有个容易踩坑的地方CSI摄像头在Orin上需要驱动层适配不同型号的CSI摄像头配置不同。建议新手先用USB接口的传感器把流程跑通再考虑CSI方案。3. SLAM与导航让机器人先认识世界再自主移动AGI机器人如果只会原地打转感知和环境理解就毫无意义。SLAM和导航是机器人在物理世界移动的基础能力。3.1 建图方案选型激光、视觉还是两者融合SLAM方案现在主流是三类第一类是2D激光SLAM代表方案是Gmapping和Cartographer。2D激光在室内平坦环境下表现稳定计算量小建图精度高适合大部分室内AGV和扫地机器人场景。第二类是视觉SLAM代表方案是ORB-SLAM3和VINS-Fusion适合室外环境或者没有激光雷达的情况。视觉SLAM的优势是信息量大能感知环境的语义和纹理信息但受光照影响明显计算量也大。第三类是激光视觉融合方案这是目前AGI机器人上实用性最强的。激光提供精确的距离信息做几何建图视觉提供语义和纹理信息做场景理解。在Orin的算力下融合方案可以实时运行。我目前的测试车就是2D激光雷达加深度相机融合建图室内环境下效果很稳。3.2 导航栈Nav2的全局规划与局部规划ROS2的导航栈叫Nav2相当于给机器人装了一个自动驾驶大脑。Nav2有四个核心模块地图服务器管理已知地图给其他模块提供地图数据。AMCL自适应蒙特卡洛定位让机器人在已知地图中确定自己位置。全局规划器在地图上规划一条从当前位置到目标点的全局路径常用算法是A*或者Dijkstra。局部规划器实时避开动态障碍物让机器人沿全局路径平滑移动。常用算法是DWA动态窗口法、TEB时间弹性带。Nav2的调参是个水很深的环节。DWA的max_vel_x、min_vel_x、max_vel_theta这些参数直接决定机器人跑起来稳不稳。我踩过最大的坑是底盘的最大角速度设得过大机器人转弯时直接甩尾表现在地图上就是轨迹扭曲定位漂移。调参思路是先改底盘参数匹配实际物理能力再改路径规划的采样空间最后调代价地图的膨胀半径。3.3 路径规划与避障代价地图的灵活运用Nav2里避障依赖的机制是代价地图Costmap它把障碍物膨胀成安全区域路径规划算法只敢走安全区。我实际使用中有一个经验障碍物膨胀半径要跟机器人尺寸挂钩但别直接等于机器人半径。膨胀半径设置太大会导致窄通道过不去太小又可能蹭到障碍物边沿。比如我的测试车宽35厘米障碍物膨胀半径设到25厘米在标准门框下通过基本无压力同时在走廊里也不会撞墙。对于AGI机器人我更推荐在代价地图之上加一个语义避障层。视觉模型检测到人、易碎品这类物体后动态生成一个临时代价区域让局部规划器提前避让。实测下来对行人的避让成功率提升明显。3.4 一轮实际跑图过程建图阶段我用的是Cartographer直观感受是比Gmapping的抗漂移能力好。跑一轮建图的流程可以总结成四步第一步启动传感器驱动确认点云和IMU数据正常。第二步启动Cartographer建图节点机器人开始累计位姿。第三步通过遥控器或者手柄控制机器人缓慢移动重点扫描房间角落、门框、桌腿这些特征丰富的区域。第四步地图生成后保存为PGM和YAML文件供导航模块加载。这里有个必须注意的小技巧角速度要控制好旋转太快的扫描时间不够容易产生畸变。我的经验是建图时线速度不超过0.3米/秒角速度不超过0.3弧度/秒宁可慢一点数据质量才有保证。4. 端侧大模型推理在AGX Orin上跑LLM和多模态模型AGI机器人和传统机器人的本质区别是理解能力。让机器人像人一样理解场景、理解自然语言指令这需要端侧的LLM和多模态模型推理能力。4.1 为什么选llama.cpp作为推理引擎在Jetson平台上部署大模型我实测了几个方案最推荐llama.cpp。llama.cpp是以C实现的大模型推理引擎它的优势对Jetson来说很关键一是纯CPU推理也能跑不强制依赖GPU在Orin这种统一内存架构上尤其合适二是通过GGUF量化方式可以把模型压到很小的内存占用范围三是对ARM架构做了针对性优化NEON指令集支持完善。对比下来Hugging Face的Transformers库在Jetson上跑大模型内存占用高、推理速度慢不适合实时机器人场景。llama.cpp配合GGUF量化是目前边缘端跑LLM最务实的选择。4.2 模型量化与部署实战从下载到推理这里给一套完整可复现的流程。选一个7B参数的中文模型比如Qwen2.5-7B-Instruct量化到Q4_K_M这是推理速度和效果比较平衡的点。第一步下载GGUF格式的模型文件。这个格式可以直接被llama.cpp加载不需要额外的转换步骤。第二步在Jetson上编译llama.cpp。ARM架构默认编译就可以支持NEON优化。如果要用GPU推理需要加CUDA支持的参数重新编译。第三步做一次基准测试。实测在AGX Orin上Q4_K_M量化后的7B模型每秒能生成15到20个token。这个速度对于机器人决策级别的对话足够用了毕竟机器人不需要像ChatGPT一样连续输出长文本它只需要理解指令、提取意图、生成执行参数。第四步把llama.cpp封装成ROS2节点。输入是自然语言指令输出是结构化的JSON比如目标物体名称、目标地点、执行动作类型。这样后续决策模块只需要解析JSON不需要直接和大模型打交道逻辑一拆就清晰了。4.3 多模态模型接入让机器人看懂世界并描述出来真正的AGI机器人需要理解视觉场景而不仅仅是检测物体。多模态大模型比如LLaVA、MiniGPT-4可以把图像直接输入模型让机器人描述场景、回答问题、进行推理。在Orin上跑多模态模型流程会稍微复杂一些Vision Encoder部分用Vision Transformer处理图像输入生成视觉特征嵌入。Text Decoder部分用LLM生成文本输出。部署技巧是视觉编码器的计算量集中在GPU上用TensorRT优化文本生成的LLM用llama.cpp的量化版本。这个混合方案能有效降低内存占用同时保持视觉理解的实时性。我实测的效果用LLaVA-1.5-7B的量化版输入一帧640x480图像加上一个这张桌子上有什么物体分别在哪的问题端到端推理时间大约3到5秒。对于离线任务分析场景够用对于实时抓取场景还需要进一步优化。4.4 边缘大模型的算力与内存调优Jetson上的内存是CPU和GPU共享的这和PC完全不同。AGX Orin的64GB内存是宝贵的统一内存池大模型、视觉SLAM、检测模型全部吃这一块。我的内存分配经验大致是大模型运行时占10GB到12GB视觉SLAM占2GB到3GB目标检测和TensorRT缓存占1GB到2GB系统与ROS2基础服务占3GB到4GB。整体控制在20GB以内剩余内存留给动态分配和缓存。如果内存吃紧有两条路一是把模型量化等级提高到Q3_K_M或者Q2_K牺牲少量精度换一半内存二是用内存交换区但Jetson的eMMC或SSD交换性能有限不建议依赖。5. 运动控制与执行器从底盘到机械臂的最后一厘米大模型能理解世界导航能规划路径但机器人最后要完成任务还是得落到运动和操作上。5.1 底盘运动学与差速控制机器人底盘做运动控制核心是运动学解算。差速底盘是应用最广的结构它的控制逻辑是接收线速度和角速度指令解算到左右轮子各自的角速度。ROS2里base_controller节点的主要功能就是把/cmd_vel上的Twist消息转换成左右轮子的转速指令。Twist里两个关键量是linear速度前进方向和angular速度旋转方向。差速底盘的控制公式是左轮速度 (线速度 - 角速度 * 轮距/2) / 轮半径右轮速度 (线速度 角速度 * 轮距/2) / 轮半径其中轮距是左右轮中心线的距离。这个参数如果和实物不一致机器人走弧线就会偏。我第一次调这个参数时没量准轮距机器人直行时明显向右偏转头在导航地图上画了一个S形。量轮距时一定要实测左右轮触地点的中心距离别拿车壳宽度凑数。5.2 终端执行器从夹爪到音圈电机机械臂的末端执行器决定了机器人能不能完成精细操作。市面上常见的方案有三类气动夹爪便宜、抓取力大但行程固定不能柔性控制力度适合工业重复抓取场景。电动夹爪用步进或伺服电机驱动能控制夹持力对易碎品友好。这类方案在服务机器人和协作机器人上比较常见。音圈电机是近几年在精密操控领域用得越来越多的方案。它的特点是响应极快、加速度高、控制精度高适合需要秒级响应的精细操作比如柔性装配、精密分拣。我做了一个简单的测试对比。执行器类型响应速度夹持力控制精度级别适用场景气动夹爪快不可调毫米级工业码垛、固定规格抓取电动夹爪中可调毫米级服务机器人、协作机器人音圈电机极快可调微米级精密装配、柔性抓取5.3 工业场景通信VDA5050与本体控制如果做的AGI机器人要进入工厂通信协议就绕不开。VDA5050是德国汽车工业联合会制定的AGV通信协议它定义了主控系统和AGV之间任务下发、状态上报、路径请求的标准接口。在AGX Orin上跑VDA5050客户端一般是作为M2M通信模块接收MES或WMS系统的任务指令解析后转成ROS2的导航目标点。这个过程里任务的状态机管理是核心需要定义好空闲、执行中、暂停、完成、失败这些状态并且在整个流程里保证消息的幂等性避免重复下发任务导致机器人重复作业。5.4 仿真先行MuJoCo在机器人开发中的价值直接上实体机器人调试容易损坏设备效率也低。我先在MuJoCo里搭好运动学模型和控制器验证好逻辑之后再部署到实体上。为什么选MuJoCo它最大的优势是物理引擎精度高、速度快对机械臂和足式机器人的支持做得非常好。MuJoCo的MJCF模型格式比起URDF要简洁很多写起来快迭代方便。我仿真的典型流程是先写好底盘和机械臂的运动学模型在MuJoCo里让它跑起来验证步态和路径规划算法再把同一套策略部署到实体机器人的控制器里。这套流程省下的调试时间怎么算都值。6. 避坑指南这些坑我踩过你别再踩前面每个环节都零散提了一些坑这节把最容易让项目卡壳的集中列一下。6.1 散热与功耗满血运行的第一前提AGX Orin满血模式跑大模型推理发热量非常大。之前我为了静音用了无风扇的散热片被动散热方案结果大模型跑了十分钟系统温度直接冲到85度然后进入降频保护推理速度掉了一半还多。后来换成带风扇的主动散热模组温度稳定在60度左右。如果是电池供电的机器人还需要在JetPack的电源管理里做好功耗档位切换。待机时用15瓦模式跑大模型时切到40瓦或60瓦模式可以延长不少续航。6.2 存储分配系统盘和缓存盘要分离Jetson的内置存储是eMMC或者NVMe SSD。我的建议是系统装在内置盘上但所有缓存、模型文件、Docker镜像全部重定向到外置大容量SSD。Docker默认的数据目录在/var/lib/docker如果不改位置一个模型镜像就能塞爆内置存储。改Docker数据目录的方式很简单编辑/etc/docker/daemon.json加一行data-root: /mnt/ssd/docker然后重启Docker服务。6.3 调试工具链远程开发与日志分析Jetson开发板放在机器人上不可能一直接显示器调试。我的远程调试方案是视频流可视化用Foxglove Studio它支持ROS2话题实时订阅可以同时看相机画面、点云、地图、路径规划结果在浏览器里打开就行。代码调试用VS Code Remote SSH在宿主机上直接编辑和调试板子上的代码断点调试、变量查看都没问题。日志查看用ROS2的ros2 bag record录制数据包后面离线回放分析问题。出现定位漂移或导航失败时回放数据包能定位到是传感器问题还是算法问题比盯着实时画面猜靠谱得多。6.4 开发节奏建议先跑通再优化最后一条经验和节奏有关。做AGI机器人项目最容易掉进去的陷阱是追求一步到位想一次性把视觉检测、大模型、SLAM导航、机械臂抓取全部调好然后再加上测试。我的建议是严格分阶段第一阶段先让底盘动起来ROS2控制节点跑通。第二阶段接入传感器做SLAM建图导航跑通。第三阶段接目标检测做视觉感知。第四阶段再上大模型做语义理解和决策。第五阶段才考虑末端执行器和精细操作。每个阶段都定义出一个可验证的里程碑比如机器人能从A点自动规划路径走到B点并避开障碍就是一个里程碑机器人能根据把红色杯子放到桌上这个指令完成抓取动作也是一个里程碑。这种方式的优势很明显每个里程碑独立调试出问题时排查范围小。如果直接追求一步到位出问题你根本不知道是导航的锅、视觉的锅还是大模型决策的锅。我个人的体会是Jetson AGX Orin这块板子的算力上限远超我的预期真正限制项目进展的往往不是硬件而是软件栈的整合能力。把感知、决策、控制这三套体系打通让它们在同一块板子上协同工作这一步跨过去之后AGI机器人的框架基本就立住了。后续再扩展机械臂、扩展新的传感器、换更好的模型都只是在既有框架上做增量。 
长河君 · 2026/9/16 5:40:33 · 阅读 1.2k Jetson AGX Orin实战：从零搭建AGI机器人完整技术栈
上篇聊了Jetson AGX Orin的选型理由和基础环境很多朋友留言问得最多的其实是同一个问题板子到了、系统刷好了然后呢这篇我把从一块Jetson AGX Orin到一臺能感知、能决策、能动起来的AGI机器人原型背后那套完整技术栈串一遍。从底层系统配置、ROS2通信骨架到SLAM建图导航再到端侧部署大模型做多模态感知最后落到运动控制和执行器思路和踩坑都会讲。适合刚入手Jetson系列、想往具身智能方向走但还没完全打通全流程的朋友参考。1. 为什么是Jetson AGX Orin一块板子背后的取舍逻辑AGI机器人听起来很遥远但落到硬件选型上核心指标无非三件事算力够不够跑感知模型、接口全不全接得齐传感器和执行器、功耗能不能被机器人本体接受。1.1 算力账从TOPS数字到实际能跑的模型Jetson AGX Orin的标称算力是275 TOPS。这个数字很多人看个热闹我帮大家拆一下实际能干什么。TOPS是INT8精度的理论峰值真实部署时要用TensorRT做模型优化跑FP16或者INT8量化。以我实测的数据YOLOv8s目标检测模型输入分辨率640x640TensorRT优化后跑FP16在Orin上能到接近200 FPS如果跑的是视觉语言模型如CLIP或者轻量VLM推理延迟大概在几十到几百毫秒级别。这意味着单块Orin足够同时跑一路视觉SLAM、一个目标检测模型、一个大语言模型做决策再加底盘控制不需要外挂显卡。对比上一代XavierOrin的CPU升级到12核Arm Cortex-A78AE这对机器人场景特别关键。机器人控制逻辑、ROS2中间件、运动学解算都是CPU密集型的GPU再强CPU跟不上一样卡。实测在Orin上同时跑导航栈和检测推理CPU占用控制在60%左右余量充足。1.2 和树莓派、x86工控机、其他加速卡怎么选很多新手纠结要不要先用树莓派练手。我的看法是如果目标就是做AGI机器人直接上Jetson系列别绕路。树莓派5的算力大约只有0.1 TOPS级别跑个yolov5n都够呛更不用说跑Transformer模型做决策。当然树莓派成本低、生态好适合学基础GPIO控制和简单避障。但如果你要做的机器人需要视觉理解、语义导航、大模型决策这些能力树莓派算力就是硬瓶颈到最后还得换平台中间写的ROS2代码虽然能迁移但硬件适配和调试时间全部浪费。x86工控机加独立显卡的方案算力最强但功耗和体积压不住机器人这个场景。AGV小车或者复合机器人一般要求整机功耗控制在几十瓦这个量级一张RTX 4060显卡功耗就115瓦了加上CPU、主板整机轻松破200瓦。AGX Orin的模块功耗在15瓦到60瓦之间可调配合电池供电能支撑几个小时的连续作业。1.3 这台配置对应什么形态的机器人按照AGX Orin的接口和算力特征比较合适的机器人形态大概三类一是移动底盘加机械臂的复合机器人。底盘负责导航机械臂负责操作Orin把所有计算扛下来。我见过最多的也是这种形态结合大模型做视觉抓取和语义导航。二是四足机器人。四足对运动控制的实时性要求极高Orin的实时性能和GPIO接口刚好够用。而且四足的负载能力通常10公斤左右正好能背一块Orin和传感器套件。三是VDA5050体系下的AGV调度节点。Orin作为车载计算单元跑导航、调度客户端和任务管理算力富余还可以加视觉避障。如果后面要对接工厂的中央调度系统VDA5050是不错的参考规范。2. 软件技术栈从底层系统到ROS2的完整骨架硬件是骨架软件是神经系统。AGI机器人的软件栈比我接触过的任何嵌入式项目都要复杂这节从底往上拆。2.1 JetPack版本与系统镜像选择Jetson平台的操作系统镜像叫JetPack里面有Ubuntu、CUDA、cuDNN、TensorRT、OpenCV这些预编译好的组件。选JetPack版本有一个原则不是越新越好而是看你的依赖生态跟不跟得上。我目前用的是JetPack 5.1.2配套Ubuntu 20.04和ROS2 Foxy。Jetson平台刷系统的思路是因为板卡架构是ARM很多开源库不会直接给Jetson发布二进制包但JetPack用SDK Manager管理会解决大部分依赖问题。如果上最新的JetPack 6.xUbuntu升级到22.04系统更新但一些底层库比如旧版TensorRT和自定义算子可能不兼容而且ROS2要切到Humble。建议新项目直接用新版但迁移老项目前先确认依赖包全部支持不然会花大量时间重新编译。2.2 容器化开发环境避免依赖地狱AGI机器人涉及Python、C、CUDA、ROS2、深度学习框架这堆依赖混在宿主机上早晚出问题。我在Jetson上强烈推荐用容器方案把开发环境、运行环境和系统镜像隔离。这里的关键是NVIDIA官方提供了Jetson容器的运行时支持JetPack自带Containerd和NVIDIA Container Toolkit可以直接跑带GPU加速的Docker容器。我自己的方案是写一套Dockerfile基于nvidia/cuda镜像装好Python依赖、ROS2和TensorRT然后挂载到宿主机上使用。Jetson容器有几个需要注意的点容器内使用CUDA需要宿主机安装NVIDIA Container Toolkit且容器启动时加--runtimenvidia参数。Docker默认的存储驱动在Jetson上性能一般建议把Docker根目录放到SSD上别放eMMC。容器内访问USB摄像头、串口这类设备启动时用--device/dev/ttyUSB0:/dev/ttyUSB0或者--privileged挂载设备节点。2.3 ROS2分布式通信AGI机器人通常会拆成传感器、感知、决策、运动控制、机械臂控制等模块这些模块之间的通信靠ROS2。ROS2基于DDS协议它的核心优势是节点分布式部署、实时性更好、支持QoS策略。ROS2的节点设计有个经验一个功能一个节点不要把所有逻辑塞进一个大节点。比如视觉检测一个节点SLAM一个节点导航一个节点大模型决策一个节点。每个节点独立编译、独立调试出问题时重启单个节点就行而不需要重启整个机器人程序。QoS配置也要注意。激光雷达点云和相机图像这种高频大流量数据用Reliable传输会导致延迟增加用Best Effort模式则更快。两者对丢包的容忍度不同。我一般做法是传感器数据用Best Effort加深度传感器协处理器控制指令用Reliable保证控制命令不丢失。2.4 数据接入摄像头、激光雷达和IMU机器人感知的第一环是数据接入。AGX Orin支持最多16路MIPI CSI输入也支持USB摄像头。我实际用的组合是Intel RealSense D435i做视觉和深度感知一个2D激光雷达做导航加上IMU模块做姿态估计。接入这些传感器最稳妥的办法是通过ROS2驱动包。RealSense和激光雷达都有现成的驱动IMU如果选的是市面上常见型号基本也能找到对应的ROS2包。这块有个容易踩坑的地方CSI摄像头在Orin上需要驱动层适配不同型号的CSI摄像头配置不同。建议新手先用USB接口的传感器把流程跑通再考虑CSI方案。3. SLAM与导航让机器人先认识世界再自主移动AGI机器人如果只会原地打转感知和环境理解就毫无意义。SLAM和导航是机器人在物理世界移动的基础能力。3.1 建图方案选型激光、视觉还是两者融合SLAM方案现在主流是三类第一类是2D激光SLAM代表方案是Gmapping和Cartographer。2D激光在室内平坦环境下表现稳定计算量小建图精度高适合大部分室内AGV和扫地机器人场景。第二类是视觉SLAM代表方案是ORB-SLAM3和VINS-Fusion适合室外环境或者没有激光雷达的情况。视觉SLAM的优势是信息量大能感知环境的语义和纹理信息但受光照影响明显计算量也大。第三类是激光视觉融合方案这是目前AGI机器人上实用性最强的。激光提供精确的距离信息做几何建图视觉提供语义和纹理信息做场景理解。在Orin的算力下融合方案可以实时运行。我目前的测试车就是2D激光雷达加深度相机融合建图室内环境下效果很稳。3.2 导航栈Nav2的全局规划与局部规划ROS2的导航栈叫Nav2相当于给机器人装了一个自动驾驶大脑。Nav2有四个核心模块地图服务器管理已知地图给其他模块提供地图数据。AMCL自适应蒙特卡洛定位让机器人在已知地图中确定自己位置。全局规划器在地图上规划一条从当前位置到目标点的全局路径常用算法是A*或者Dijkstra。局部规划器实时避开动态障碍物让机器人沿全局路径平滑移动。常用算法是DWA动态窗口法、TEB时间弹性带。Nav2的调参是个水很深的环节。DWA的max_vel_x、min_vel_x、max_vel_theta这些参数直接决定机器人跑起来稳不稳。我踩过最大的坑是底盘的最大角速度设得过大机器人转弯时直接甩尾表现在地图上就是轨迹扭曲定位漂移。调参思路是先改底盘参数匹配实际物理能力再改路径规划的采样空间最后调代价地图的膨胀半径。3.3 路径规划与避障代价地图的灵活运用Nav2里避障依赖的机制是代价地图Costmap它把障碍物膨胀成安全区域路径规划算法只敢走安全区。我实际使用中有一个经验障碍物膨胀半径要跟机器人尺寸挂钩但别直接等于机器人半径。膨胀半径设置太大会导致窄通道过不去太小又可能蹭到障碍物边沿。比如我的测试车宽35厘米障碍物膨胀半径设到25厘米在标准门框下通过基本无压力同时在走廊里也不会撞墙。对于AGI机器人我更推荐在代价地图之上加一个语义避障层。视觉模型检测到人、易碎品这类物体后动态生成一个临时代价区域让局部规划器提前避让。实测下来对行人的避让成功率提升明显。3.4 一轮实际跑图过程建图阶段我用的是Cartographer直观感受是比Gmapping的抗漂移能力好。跑一轮建图的流程可以总结成四步第一步启动传感器驱动确认点云和IMU数据正常。第二步启动Cartographer建图节点机器人开始累计位姿。第三步通过遥控器或者手柄控制机器人缓慢移动重点扫描房间角落、门框、桌腿这些特征丰富的区域。第四步地图生成后保存为PGM和YAML文件供导航模块加载。这里有个必须注意的小技巧角速度要控制好旋转太快的扫描时间不够容易产生畸变。我的经验是建图时线速度不超过0.3米/秒角速度不超过0.3弧度/秒宁可慢一点数据质量才有保证。4. 端侧大模型推理在AGX Orin上跑LLM和多模态模型AGI机器人和传统机器人的本质区别是理解能力。让机器人像人一样理解场景、理解自然语言指令这需要端侧的LLM和多模态模型推理能力。4.1 为什么选llama.cpp作为推理引擎在Jetson平台上部署大模型我实测了几个方案最推荐llama.cpp。llama.cpp是以C实现的大模型推理引擎它的优势对Jetson来说很关键一是纯CPU推理也能跑不强制依赖GPU在Orin这种统一内存架构上尤其合适二是通过GGUF量化方式可以把模型压到很小的内存占用范围三是对ARM架构做了针对性优化NEON指令集支持完善。对比下来Hugging Face的Transformers库在Jetson上跑大模型内存占用高、推理速度慢不适合实时机器人场景。llama.cpp配合GGUF量化是目前边缘端跑LLM最务实的选择。4.2 模型量化与部署实战从下载到推理这里给一套完整可复现的流程。选一个7B参数的中文模型比如Qwen2.5-7B-Instruct量化到Q4_K_M这是推理速度和效果比较平衡的点。第一步下载GGUF格式的模型文件。这个格式可以直接被llama.cpp加载不需要额外的转换步骤。第二步在Jetson上编译llama.cpp。ARM架构默认编译就可以支持NEON优化。如果要用GPU推理需要加CUDA支持的参数重新编译。第三步做一次基准测试。实测在AGX Orin上Q4_K_M量化后的7B模型每秒能生成15到20个token。这个速度对于机器人决策级别的对话足够用了毕竟机器人不需要像ChatGPT一样连续输出长文本它只需要理解指令、提取意图、生成执行参数。第四步把llama.cpp封装成ROS2节点。输入是自然语言指令输出是结构化的JSON比如目标物体名称、目标地点、执行动作类型。这样后续决策模块只需要解析JSON不需要直接和大模型打交道逻辑一拆就清晰了。4.3 多模态模型接入让机器人看懂世界并描述出来真正的AGI机器人需要理解视觉场景而不仅仅是检测物体。多模态大模型比如LLaVA、MiniGPT-4可以把图像直接输入模型让机器人描述场景、回答问题、进行推理。在Orin上跑多模态模型流程会稍微复杂一些Vision Encoder部分用Vision Transformer处理图像输入生成视觉特征嵌入。Text Decoder部分用LLM生成文本输出。部署技巧是视觉编码器的计算量集中在GPU上用TensorRT优化文本生成的LLM用llama.cpp的量化版本。这个混合方案能有效降低内存占用同时保持视觉理解的实时性。我实测的效果用LLaVA-1.5-7B的量化版输入一帧640x480图像加上一个这张桌子上有什么物体分别在哪的问题端到端推理时间大约3到5秒。对于离线任务分析场景够用对于实时抓取场景还需要进一步优化。4.4 边缘大模型的算力与内存调优Jetson上的内存是CPU和GPU共享的这和PC完全不同。AGX Orin的64GB内存是宝贵的统一内存池大模型、视觉SLAM、检测模型全部吃这一块。我的内存分配经验大致是大模型运行时占10GB到12GB视觉SLAM占2GB到3GB目标检测和TensorRT缓存占1GB到2GB系统与ROS2基础服务占3GB到4GB。整体控制在20GB以内剩余内存留给动态分配和缓存。如果内存吃紧有两条路一是把模型量化等级提高到Q3_K_M或者Q2_K牺牲少量精度换一半内存二是用内存交换区但Jetson的eMMC或SSD交换性能有限不建议依赖。5. 运动控制与执行器从底盘到机械臂的最后一厘米大模型能理解世界导航能规划路径但机器人最后要完成任务还是得落到运动和操作上。5.1 底盘运动学与差速控制机器人底盘做运动控制核心是运动学解算。差速底盘是应用最广的结构它的控制逻辑是接收线速度和角速度指令解算到左右轮子各自的角速度。ROS2里base_controller节点的主要功能就是把/cmd_vel上的Twist消息转换成左右轮子的转速指令。Twist里两个关键量是linear速度前进方向和angular速度旋转方向。差速底盘的控制公式是左轮速度 (线速度 - 角速度 * 轮距/2) / 轮半径右轮速度 (线速度 角速度 * 轮距/2) / 轮半径其中轮距是左右轮中心线的距离。这个参数如果和实物不一致机器人走弧线就会偏。我第一次调这个参数时没量准轮距机器人直行时明显向右偏转头在导航地图上画了一个S形。量轮距时一定要实测左右轮触地点的中心距离别拿车壳宽度凑数。5.2 终端执行器从夹爪到音圈电机机械臂的末端执行器决定了机器人能不能完成精细操作。市面上常见的方案有三类气动夹爪便宜、抓取力大但行程固定不能柔性控制力度适合工业重复抓取场景。电动夹爪用步进或伺服电机驱动能控制夹持力对易碎品友好。这类方案在服务机器人和协作机器人上比较常见。音圈电机是近几年在精密操控领域用得越来越多的方案。它的特点是响应极快、加速度高、控制精度高适合需要秒级响应的精细操作比如柔性装配、精密分拣。我做了一个简单的测试对比。执行器类型响应速度夹持力控制精度级别适用场景气动夹爪快不可调毫米级工业码垛、固定规格抓取电动夹爪中可调毫米级服务机器人、协作机器人音圈电机极快可调微米级精密装配、柔性抓取5.3 工业场景通信VDA5050与本体控制如果做的AGI机器人要进入工厂通信协议就绕不开。VDA5050是德国汽车工业联合会制定的AGV通信协议它定义了主控系统和AGV之间任务下发、状态上报、路径请求的标准接口。在AGX Orin上跑VDA5050客户端一般是作为M2M通信模块接收MES或WMS系统的任务指令解析后转成ROS2的导航目标点。这个过程里任务的状态机管理是核心需要定义好空闲、执行中、暂停、完成、失败这些状态并且在整个流程里保证消息的幂等性避免重复下发任务导致机器人重复作业。5.4 仿真先行MuJoCo在机器人开发中的价值直接上实体机器人调试容易损坏设备效率也低。我先在MuJoCo里搭好运动学模型和控制器验证好逻辑之后再部署到实体上。为什么选MuJoCo它最大的优势是物理引擎精度高、速度快对机械臂和足式机器人的支持做得非常好。MuJoCo的MJCF模型格式比起URDF要简洁很多写起来快迭代方便。我仿真的典型流程是先写好底盘和机械臂的运动学模型在MuJoCo里让它跑起来验证步态和路径规划算法再把同一套策略部署到实体机器人的控制器里。这套流程省下的调试时间怎么算都值。6. 避坑指南这些坑我踩过你别再踩前面每个环节都零散提了一些坑这节把最容易让项目卡壳的集中列一下。6.1 散热与功耗满血运行的第一前提AGX Orin满血模式跑大模型推理发热量非常大。之前我为了静音用了无风扇的散热片被动散热方案结果大模型跑了十分钟系统温度直接冲到85度然后进入降频保护推理速度掉了一半还多。后来换成带风扇的主动散热模组温度稳定在60度左右。如果是电池供电的机器人还需要在JetPack的电源管理里做好功耗档位切换。待机时用15瓦模式跑大模型时切到40瓦或60瓦模式可以延长不少续航。6.2 存储分配系统盘和缓存盘要分离Jetson的内置存储是eMMC或者NVMe SSD。我的建议是系统装在内置盘上但所有缓存、模型文件、Docker镜像全部重定向到外置大容量SSD。Docker默认的数据目录在/var/lib/docker如果不改位置一个模型镜像就能塞爆内置存储。改Docker数据目录的方式很简单编辑/etc/docker/daemon.json加一行data-root: /mnt/ssd/docker然后重启Docker服务。6.3 调试工具链远程开发与日志分析Jetson开发板放在机器人上不可能一直接显示器调试。我的远程调试方案是视频流可视化用Foxglove Studio它支持ROS2话题实时订阅可以同时看相机画面、点云、地图、路径规划结果在浏览器里打开就行。代码调试用VS Code Remote SSH在宿主机上直接编辑和调试板子上的代码断点调试、变量查看都没问题。日志查看用ROS2的ros2 bag record录制数据包后面离线回放分析问题。出现定位漂移或导航失败时回放数据包能定位到是传感器问题还是算法问题比盯着实时画面猜靠谱得多。6.4 开发节奏建议先跑通再优化最后一条经验和节奏有关。做AGI机器人项目最容易掉进去的陷阱是追求一步到位想一次性把视觉检测、大模型、SLAM导航、机械臂抓取全部调好然后再加上测试。我的建议是严格分阶段第一阶段先让底盘动起来ROS2控制节点跑通。第二阶段接入传感器做SLAM建图导航跑通。第三阶段接目标检测做视觉感知。第四阶段再上大模型做语义理解和决策。第五阶段才考虑末端执行器和精细操作。每个阶段都定义出一个可验证的里程碑比如机器人能从A点自动规划路径走到B点并避开障碍就是一个里程碑机器人能根据把红色杯子放到桌上这个指令完成抓取动作也是一个里程碑。这种方式的优势很明显每个里程碑独立调试出问题时排查范围小。如果直接追求一步到位出问题你根本不知道是导航的锅、视觉的锅还是大模型决策的锅。我个人的体会是Jetson AGX Orin这块板子的算力上限远超我的预期真正限制项目进展的往往不是硬件而是软件栈的整合能力。把感知、决策、控制这三套体系打通让它们在同一块板子上协同工作这一步跨过去之后AGI机器人的框架基本就立住了。后续再扩展机械臂、扩展新的传感器、换更好的模型都只是在既有框架上做增量。