从Figure热议看机器人开发：感知、规划到仿真全栈拆解

这轮 Figure 创始人谈中国机器人的讨论最近在开发者社群里刷屏了。刷屏的原因不只是“哪边技术更强”的口水仗而是它把三个话题一次性抛了出来人形机器人到底能不能真正落地中国机器人供应链的真实能力到了什么程度多模态大模型与机器人结合又走到了哪一步。对做机器人开发的工程师来说这其实是一轮很好的技术复盘素材。这篇文章不从“谁赢谁输”的立场去聊而是站在机器人研发工程师的视角把这次热议背后的技术链条拆开从核心栈、感知定位、路径规划与控制到仿真平台选型、大模型融合再落地到工业与协作机器人开发时真正需要注意的安全、通信和选型问题。读完你应该能搞清楚如果自己要搭一套机器人系统优先打通哪些模块如果公司正在做人形机器人、AGV 或者协作机械臂项目哪些才是真正的技术难点。内容覆盖了 ROS2、SLAM/导航、MoveIt、仿真平台、多机器人路径规划、大模型与机器人的结合方式也整理了开发者在学习路径、工程启动顺序和常见排错方法上的实用建议。适合正在接触机器人导航、机器人感知、运动控制或具身智能方向的研发工程师、在校学生以及做自动化产线和机器人选型的技术负责人。1. 事件背景Figure 是谁这轮热议在谈什么Figure AI 是做通用人形机器人的公司方向是让机器人在工厂、仓库、家庭等场景里完成物理任务而不是只做展示用的“行走 demo”。它的技术路线比较激进整机硬件与端侧模型并行迭代早期与语言模型团队合作后机器人可以直接理解自然语言指令并拆解成动作。这在通用人形机器人赛道里属于走得比较靠前的方案。这轮热议的导火索是创始人在公开访谈和社交平台上谈到对中国机器人公司的看法核心观点可以概括为中国同行在供应链整合、整机迭代速度和成本控制上非常快部分人形机器人公司已经进入小规模试产和工厂试用阶段。这个表态之所以引发讨论是因为它打破了“人形机器人依然是国外全面领先”的旧印象把中国机器人真实的技术水位重新拉回到大家面前。技术圈讨论的其实不是情绪而是几个非常客观的问题关节电机、减速器、灵巧手、传感器这些核心硬件中国供应链哪些环节真的成熟。整机集成和量产能力在成本和良率上谁更有优势。软件栈、数据采集和运动控制算法国内外差距到底还有多大。大模型接入之后人形机器人的“大脑”能不能在真实场景里稳定跑起来。从工程师视角看最有价值的不是简单比较而是这轮热议把“人形机器人能否落地”的技术链条重新拆开了一遍。终端形态是“人形”还是“轮式底盘”短期可能不重要真正决定项目成败的是感知、决策、运动控制和系统集成这些底层能力。2. 人形机器人核心技术栈速览不管做的是人形机器人还是工业机械臂、AGV、协作机器人底层技术栈都有很强的一致性。下面这张表可以作为通用框架。技术模块核心内容常见工具 / 方案关键指标感知视觉、激光、触觉、惯性RGB-D 相机、激光雷达、IMU、力传感器帧率、点云密度、延迟定位导航地图构建与实时定位SLAM、Nav2、EKF、因子图优化定位精度、漂移率、重定位速度路径规划全局路径、局部避障、多机调度A*、RRT、TEB、DWA、CBS规划耗时、成功率、动态避障能力运动控制关节级/整机级运动解算运动学、逆解、MPC、WBC、MoveIt轨迹跟踪误差、稳定性、抖动任务决策任务拆解与执行编排状态机、行为树、LLM/VLA 模型任务成功率、响应时延中间件消息通信、状态管理、日志ROS/ROS2、EtherCAT、DDS实时性、带宽、节点可维护性能源与结构电池、关节电机、散热、整机刚度无框电机、谐波减速器、行星减速器能量密度、关节峰值扭矩人形机器人最大的难点在于它不是一个单一算法问题而是把高实时感知、强算力决策、复杂动力学控制塞进一个体积有限、功耗有限的躯体里。任何一个模块拖后腿整机能力就起不来。从这次热议看中国机器人的优势更多体现在第三行和第七行供应链完整、硬件迭代快、整机成本控制能力强。而模型迭代、数据采集、高自由度运动控制算法仍是全球范围内的共同挑战这也是开发者可以切入的机会点。3. 中国机器人产业的技术版图热搜词里有大量工业机器人品牌和开发关键词比如 ABB、发那科、安川、库卡、埃夫特、法奥协作机器人、安川机器人 IO、发那科机器人原点数据变量、ABB 机器人 SDK 控制运动。这些词的密集出现说明行业关注点不只在炫酷的人形机器人还在大量存量工业机器人的调试、二次开发与自动化集成。可以把中国机器人相关产业链分成四类来理解3.1 传统工业机器人以六轴/四轴手臂为主用于焊接、搬运、喷涂、码垛。国外品牌起步早控制器、伺服驱动和动力学算法成熟国内埃斯顿、埃夫特、新时达、汇川等厂商在控制器和伺服层面快速追赶。工程开发中经常要做的工作包括通过 SDK 读取机器人状态、控制运动、设置 IO 信号以及处理“原点数据变量”“远程启动 PNS”这类现场问题。3.2 协作机器人相对于传统工业机器人协作机器人更强调安全性、易用性和人机共融。国内代表厂商包括遨博、节卡、越疆、法奥等。开发重点在拖动示教、碰撞检测、力控、视觉引导抓取以及视觉安全区域设置。3.3 人形机器人初创公司优必选、宇树、智元、傅利叶、星动纪元等在这一轮热潮中大量进入公众视野。它们的特点是把“能走、能看、能对话、能操作”作为产品原型目标硬件迭代很快甚至开始进入工厂试用。但从软件成熟度来说开源生态和稳定工具链仍处于早期大部分功能需要工程团队自己做闭环。3.4 物流与服务机器人AMR、无人叉车、配送机器人等“机器人导航”“机器人定位”关键词主要集中在这一类。SLAM 和路径规划技术相对成熟通常跑 ROS2 或商业导航框架配合多机器人调度系统使用。也有不少开发者用开源问答机器人框架配合大模型做交互入口。从产业角度讲这轮 Figure 创始人的话之所以让很多人共鸣是因为中国机器人已经不再是“只做代工”的阶段而是出现了大量整机设计、量产试产和规模化交付的真实案例。但对工程师来说硬件能力只是入场券软件和数据的短板还要花很长时间补。4. 感知与定位从传感器到 SLAM 的落地路径做机器人开发第一关不是“让它动”而是“让它知道自己在哪里看到了什么”。感知与定位属于所有移动机器人项目的地基层。4.1 传感器选型移动机器人常用的传感器组合传感器用途注意事项2D 激光雷达建图、避障、导航成本低、适用室内扫描范围有限3D 激光雷达高精度建图与定位点云数据量大需要高性能计算RGB-D 相机物体识别、抓取、深度感知强光下深度质量下降双目相机立体视觉、深度估计对纹理和光照敏感IMU姿态估计、里程计融合漂移严重需要滤波或因子图优化编码器轮式里程计打滑场景下误差累积力/力矩传感器力控、装配、人机交互通常用于机械臂末端4.2 SLAM 方案怎么选做机器人导航项目最常见的选型是室内 2D 导航优先用 Cartographer在 ROS1/ROS2 社区都有成熟版本适合中小型室内场景。视觉/激光融合LIO-SAM、FAST-LIO 这类 LiDAR-Inertial 方案适合室外和复杂环境。纯视觉 SLAMORB-SLAM3适合没有激光雷达的低成本平台但鲁棒性需要工程调优。如果采用 ROS2可以用如下流程启动 SLAM 工具的通用 demo实际包名和参数要按你使用的发行版和机器人模型调整# 安装必要依赖以 ROS2 Humble 为例实际版本按系统为准 sudo apt install ros-humble-cartographer ros-humble-cartographer-ros # 启动机器人底层驱动节点这里用一个占位 launch 文件示意 ros2 launch my_robot_bringup robot.launch.py # 启动 cartographer 建图 ros2 launch cartographer_ros cartographer.launch.py \ config_file:my_robot_2d.lua建图完成后要进行保存地图并做纯定位测试。判断定位是否可用的标准不是“地图能显示”而是机器人在运动一段距离后激光点云与地图边缘不出现明显错位重定位时能从任意位置快速找回全局位姿。4.3 视觉识别与抓取如果机器人需要执行“识别物体-抓取-放置”这类任务就需要视觉感知与机械臂协作。通常流程是RGB-D 相机获取彩色图和深度图。目标检测模型输出目标框和类别。深度图对齐后得到目标在相机坐标系下的 3D 位置。坐标变换到机器人基坐标系下。控制机械臂运动到抓取点执行抓取。示例的 Python 伪代码流程如下import cv2 import numpy as np # 这里以本地调用为例实际项目需要替换为你的相机模型和检测模型 color_image cv2.imread(input/table_scene.jpg) depth_image cv2.imread(input/table_scene_depth.png, cv2.IMREAD_UNCHANGED) # 目标检测模块输出假设已经得到目标框 detections [ {label: bottle, bbox: [210, 140, 330, 300]}, ] for det in detections: x1, y1, x2, y2 det[bbox] # 取目标中心像素 u, v int((x1 x2) / 2), int((y1 y2) / 2) # 查深度值 z depth_image[v, u] / 1000.0 # 使用相机内参反投影到相机坐标系 fx, fy, cx, cy 615.0, 615.0, 320.0, 240.0 x (u - cx) * z / fx y (v - cy) * z / fy print(f目标 {det[label]} 的相机坐标: ({x:.3f}, {y:.3f}, {z:.3f}))这里没有给出真实内参需要你根据实际相机标定结果替换。更稳妥的做法是用标定板或厂商 SDK 获取内参避免直接套默认值。5. 路径规划与运动控制从 MoveIt 到运控闭环感知拿到环境信息后下一步就是规划一条能走的路径或者规划一条机械臂运动的轨迹。5.1 移动底盘的路径规划全局路径规划常用 A*、Dijkstra、RRT在 ROS2 Nav2 中已经封装成完整插件。局部路径规划常用 DWA、TEB、MPC其中 TEB 对动态障碍物和机器人运动学约束支持更好但参数调起来更耗时。如果采用 Nav2在nav2_params.yaml里常见的配置片段类似planner_server: ros__parameters: planner_plugins: [GridBased] GridBased: plugin: nav2_navfn_planner/NavfnPlanner tolerance: 0.5 use_astar: true controller_server: ros__parameters: controller_plugins: [FollowPath] FollowPath: plugin: nav2_dwb_controller/DWBLocalPlanner min_vel_x: 0.0 max_vel_x: 0.5 max_vel_theta: 1.0实际应用时要按机器人底盘的最大速度、加速度和电机特性调整不能照抄。5.2 多机器人路径规划热搜词里有一篇论文标题是《一种基于改进冲突搜索的多机器人路径规划算法》这正好对应仓储物流、工厂里多台 AGV 同时运行的问题。多机器人路径规划中基础做法是“先独立规划再检查冲突”一旦发生路径冲突就进行等待或重规划。改进冲突搜索CBS这一类算法通过高层冲突搜索和低层单机路径规划配合能系统性解决多机死锁问题。工程上更简单的做法是引入交通管制给每台机器人分配优先权区域锁或者设置单向车道。先保证系统不卡死再考虑效率优化。5.3 机械臂运动控制机械臂规划通常使用 MoveIt。启动一个机械臂仿真环境的通用流程# 加载机器人描述和 move_group示例需按你的机械臂 URDF 调整 ros2 launch my_robot_moveit_config move_group.launch.py # 启动 RViz 可视化 ros2 launch my_robot_moveit_config moveit_rviz.launch.py在 MoveIt 里逆运动学求解器、规划器插件OMPL 等都可以通过配置文件指定。六轴机械臂的常规任务用运动学闭式解或数值解都能解决人形机器人则因为自由度更多、约束更复杂需要使用全身控制或模型预测控制MPC通常在关节空间做优化并加入质心、落脚点、接触力等约束。如果你的项目偏研究型可以关注pinocchio、mujoco、dm_control这类库它们更适合做动力学建模和强化学习环境。实际工程中先用仿真验证运动学可行性再上真机是降低风险最有效的路径。6. 仿真先行机器人仿真平台怎么选从图中材料看“机器人仿真平台选择”是很多开发者关注的问题。选型没有唯一答案关键是匹配项目阶段平台特点适合场景Gazebo / Ignition与 ROS 集成好物理引擎成熟室内外移动机器人、多机器人仿真Webots轻量、跨平台、建模简单教育、快速验证算法逻辑CoppeliaSim支持 Lua/Python/C API功能全面机械臂、复合机器人、视觉仿真MuJoCo接触仿真精度高、速度快强化学习、人形机器人控制研究Isaac Sim基于 Omniverse视觉渲染真实具身智能、大规模数据生成、VLA 训练PyBullet轻量、易用、开发灵活算法原型、课程作业在 ROS2 下启动 Gazebo 仿真常见步骤是# 以 ROS2 Humble 为例安装 gazebo sudo apt install ros-humble-gazebo-ros-pkgs # 启动一个空白世界再加载机器人模型示例 ros2 launch gazebo_ros gazebo.launch.py world:worlds/empty.world # 生成机器人模型模型路径需要替换 ros2 run gazebo_ros spawn_entity.py \ -topic robot_description \ -entity my_robot \ -x 0.0 -y 0.0 -z 0.1仿真最重要的价值是把算法验证、参数调优和故障排查从真机搬到了桌面环境尤其在碰撞检测、多传感器融合、强化学习训练这些环节成本优势非常明显。不过仿真结果不能直接当真机指标使用。sim-to-real 的差距主要来自物理引擎不精确、传感器噪声建模不准、执行器延迟被忽略。想缩小差距可以在仿真里加入传感器噪声、随机化物理参数、模拟通信延迟再逐步迁移到真机小范围验证。如果你刚开始接触一款新的机器人平台建议先花一周时间把“URDF 导入-仿真启动-传感器输出-基本控制”跑通再去碰算法。7. 大模型与机器人结合具身智能正在改变交互方式Figure 机器人的核心卖点之一就是让机器人具备自然语言交互能力。用户说一句“把桌上的红色杯子拿过来”机器人需要完成语义理解、目标定位、路径规划、抓取决策和运动执行。这个链路被统称为“具身智能”也是最近两年大模型和机器人交叉方向最火的切入点。大模型在机器人系统里主要承担两个角色任务级语义理解把自然语言指令拆解为子任务序列。感知与动作的端到端映射VLAVision-Language-Action模型直接输出动作指令或目标位置。技术路线上RT-2、PaLM-E、OpenVLA以及国内多个团队推出的 VLA 模型都在尝试让机器人直接读取视觉和语言输入生成低层动作。但真正落地时还面临几个工程瓶颈瓶颈表现应对思路数据不足高质量机器人操作数据获取成本极高真机采集 遥操作 仿真自动生成实时性不足大模型推理延迟高端侧小模型 GPU 加速 任务缓存泛化不足场景一换就失效域随机化 多场景数据混合安全风险模型错误指令导致危险动作加入规则安全层、人工急停、速度限制对于普通开发者现阶段最实用的做法不是从零训练 VLA而是把大模型放在任务计划层先用 LLM 把用户指令转换成结构化任务再用传统规划和控制栈去执行。例如user_command 把桌上的红色杯子拿到托盘里 # 假设这是大模型的任务拆解输出 tasks [ {action: locate, target: red_cup}, {action: move_to, target: table_side}, {action: grasp, target: red_cup}, {action: move_to, target: tray}, {action: place, target: red_cup, destination: tray}, ] for task in tasks: print(f执行任务: {task[action]} - {task.get(target)}) # 每个动作由感知、规划、控制模块执行这套思路的好处是工程风险可控大模型出错时能被传统规则兜底。你也可以在本地部署一些轻量开源问答模型来做交互层再调用 ROS2 action 服务去执行机器人任务形成一条完整的“对话机器人-任务解析-机器人控制”链路。不过不管是开源大模型还是商业 API都要注意数据合规不要将涉密、隐私或未经授权的数据传入第三方接口。机器人本体如果带摄像头还要充分考虑个人信息保护在采集和存储端做脱敏处理。8. 工业与协作机器人开发注意事项热搜词里出现大量 ABB、发那科、安川、埃夫特、法奥协作机器人的关键词这也提醒我们真正规模化落地、创造产值的机器人项目很大一部分依然是传统工业机器人和协作机器人。这个方向的技术含量不低而且更需要工程经验。8.1 安全标准与硬件防护工业机器人项目最先看的一定是安全而不是算法。相关标准中ISO 10218 系列和 ISO/TS 15066 是工业机器人与协作机器人安全设计的重要参考。现场容易踩的坑包括安全围栏和光栅没有接入急停回路只做了软件减速。协作机器人速度/力限制没有按实际场景重新标定。机器人启动自动操作模式时没有确认人员是否已经离开危险区域。远程启动 PNS 这类外部启停信号没有考虑误触发的连锁反应。无论项目多小都建议保留独立的硬件急停回路不要让软件逻辑作为唯一安全依赖。任何技术分享都不应该跳过安全边界和合法授权要求。8.2 IO 控制与品牌 SDK工业机器人调试中最常遇到的不是路径规划问题而是信号交互问题。比如发那科机器人远程启动 PNS需要确认 PNS 信号分配、远程置为 REMOTE 模式。安川机器人 IO 映射不同型号的输入输出编号和功能定义可能有差异。ABB 机器人 SDK 控制运动通常走 RAPID 程序或 External Guide需要确认通信协议和权限。库卡机器人的 WHILE 循环、信号等待逻辑常用于 PLC 交互。这类问题的通用排查方法是把机器人一侧的信号状态、PLC 一侧的信号状态以及网络/总线状态三端对比。很多时候是信号没有握手或地址映射错位而不是机器人本身故障。8.3 EtherCAT 与实时控制如果自己造机器人实时通信层通常绕不开 EtherCAT。关节控制器、伺服驱动器、IO 模块通过 EtherCAT 总线同步主站需要保证周期稳定。常见周期是 1ms 或 2ms通信抖动过大就直接表现为关节抖动。调试这类系统时建议先用厂家自带的上位机工具跑通单关节点动再做整机同步运动。不要一上来就跑复杂轨迹否则关节温度、过流报警会淹没真正的问题。9. 给机器人开发者的学习与工程建议如果你想进入这个领域或者正在从纯算法岗位转向机器人系统集成建议按下面的顺序推进。9.1 先修三个基础编程语言Python 和 C 至少各能完成一个实际项目。ROS2理解节点、话题、服务、动作四大通信模型能够自己写一个 publisher 和 subscriber。坐标变换能清楚描述世界坐标系、机器人基座标系、相机坐标系、工具坐标系之间的关系。9.2 按四层递进学习第一层中间件与通信。跑通 ROS2 的 demo理解 DDS 和 QoS 对实时性的影响。第二层感知与定位。用开源数据集或仿真环境跑通 SLAM、目标检测、深度估计。第三层导航与运控。在仿真里让底盘从 A 点走到 B 点让机械臂完成“抓取-放置”闭环。第四层系统集成。把感知、导航、机械臂、语音交互、大模型任务拆解接成一个完整 demo。每层都先做最小可运行闭环再逐步加功能。9.3 工程习惯模型文件、输入素材、输出结果分目录管理不要堆在一个文件夹里。每次实验记录参数、环境版本和日志回放数据要比口头描述更可靠。批量实验要加超时和失败重试。真机实验前写好检查清单确认急停、安全围栏、通信正常。涉及人脸、声音、版权素材或客户生产数据时必须确认授权和合规边界不要拿真实数据直接训练或上传外部接口。10. 常见问题与排查方法以下问题在机器人项目里出现频率很高可以按表格思路排查。问题现象可能原因排查方式解决方案SLAM 建图漂移激光雷达帧率不足、里程计不准、回环闭环失败打开可视化看激光帧与地图边缘增加回环检测频率、融合 IMU、优化里程计标定机器人导航时乱走代价地图参数不对、定位丢失、局部规划器参数过激进检查全局和局部代价地图显示重新标定传感器、降低最大速度、调整膨胀层MoveIt 规划失败机械臂初始位姿奇异、目标点不可达、自碰撞查看规划失败反馈和轨迹可视化调整目标姿态、增加规划重试、手动移动接近目标机械臂真机抖动通信周期不稳定、PID 参数不合适、机械共振检查控制周期和电机温度和电流关闭谐振频率附近的增益、降低速度、检查 EtherCAT仿真与真机差距大物理参数不准确、传感器噪声缺失、执行器延迟被忽略对比关节角度和轨迹跟踪误差加入噪声和延迟、做参数辨识、控制测试范围多机器人调度死锁路径规划未考虑冲突、资源锁竞争查看各机器人轨迹和占用地图引入交通管制、优先级、改进冲突搜索算法大模型任务执行错误模型理解偏差、目标识别错误、安全边界缺失记录模型输入输出、检查中间任务序列增加规则校验、人工确认、使用更细粒度任务描述排查问题时要养成一个习惯先确认传感器和通信是否正常再看算法输出。超过一半的机器人调试时间花在数据采集、传感器标定和通信链路上而不是规划算法本身。11. 总结与下一步这次 Figure 创始人谈中国机器人引发的热议最重要的价值不是“谁比谁强”而是让更多人看到了一个事实机器人行业的竞争已经从单点算法竞赛转移到了“硬件供应链 软件栈 数据闭环 量产交付”的综合能力竞赛。中国机器人产业在供应链、整机迭代和成本控制上确实很快但感知算法、运动控制、高质量数据和稳定工具链仍然是需要持续投入的方向。如果你是一名开发者和学习者我最值得一试的路径是先选一套成熟仿真环境跑通 ROS2 SLAM 导航 机械臂运动规划的最小闭环再逐步加入大模型任务拆解和真实硬件平台。最容易踩的坑是跳过安全和数据验证直接上真机或者在仿真参数上过度调优忽略了真实环境里的传感器噪声和通信延迟。接下来可以重点关注几个方向开源 VLA 模型和机器人数据集的进展人形机器人整机成本的下降趋势以及工业机器人与人形机器人共用技术栈的融合趋势。建议收藏这篇文章按章节做一份自己的技术清单边做项目边回来对照。先跑通再优化最后再谈超越。