企业官网建设流程全解析

这轮 Figure 创始人谈中国机器人的讨论，最近在开发者社群里刷屏了。刷屏的原因不只是“哪边技术更强”的口水仗，而是它把三个话题一次性抛了出来：人形机器人到底能不能真正落地，中国机器人供应链的真实能力到了什么程度，多模态大模型与机器人结合又走到了哪一步。对做机器人开发的工程师来说，这其实是一轮很好的技术复盘素材。

这篇文章不从“谁赢谁输”的立场去聊，而是站在机器人研发工程师的视角，把这次热议背后的技术链条拆开：从核心栈、感知定位、路径规划与控制，到仿真平台选型、大模型融合，再落地到工业与协作机器人开发时真正需要注意的安全、通信和选型问题。读完你应该能搞清楚，如果自己要搭一套机器人系统，优先打通哪些模块；如果公司正在做人形机器人、AGV 或者协作机械臂项目，哪些才是真正的技术难点。

内容覆盖了 ROS2、SLAM/导航、MoveIt、仿真平台、多机器人路径规划、大模型与机器人的结合方式，也整理了开发者在学习路径、工程启动顺序和常见排错方法上的实用建议。适合正在接触机器人导航、机器人感知、运动控制或具身智能方向的研发工程师、在校学生，以及做自动化产线和机器人选型的技术负责人。

1. 事件背景：Figure 是谁，这轮热议在谈什么

Figure AI 是做通用人形机器人的公司，方向是让机器人在工厂、仓库、家庭等场景里完成物理任务，而不是只做展示用的“行走 demo”。它的技术路线比较激进，整机硬件与端侧模型并行迭代，早期与语言模型团队合作后，机器人可以直接理解自然语言指令并拆解成动作。这在通用人形机器人赛道里属于走得比较靠前的方案。

这轮热议的导火索，是创始人在公开访谈和社交平台上谈到对中国机器人公司的看法，核心观点可以概括为：中国同行在供应链整合、整机迭代速度和成本控制上非常快，部分人形机器人公司已经进入小规模试产和工厂试用阶段。这个表态之所以引发讨论，是因为它打破了“人形机器人依然是国外全面领先”的旧印象，把中国机器人真实的技术水位重新拉回到大家面前。

技术圈讨论的其实不是情绪，而是几个非常客观的问题：

• 关节电机、减速器、灵巧手、传感器这些核心硬件，中国供应链哪些环节真的成熟。
• 整机集成和量产能力，在成本和良率上谁更有优势。
• 软件栈、数据采集和运动控制算法，国内外差距到底还有多大。
• 大模型接入之后，人形机器人的“大脑”能不能在真实场景里稳定跑起来。

从工程师视角看，最有价值的不是简单比较，而是这轮热议把“人形机器人能否落地”的技术链条重新拆开了一遍。终端形态是“人形”还是“轮式底盘”，短期可能不重要；真正决定项目成败的，是感知、决策、运动控制和系统集成这些底层能力。

2. 人形机器人核心技术栈速览

不管做的是人形机器人，还是工业机械臂、AGV、协作机器人，底层技术栈都有很强的一致性。下面这张表可以作为通用框架。

人形机器人最大的难点在于：它不是一个单一算法问题，而是把高实时感知、强算力决策、复杂动力学控制塞进一个体积有限、功耗有限的躯体里。任何一个模块拖后腿，整机能力就起不来。

从这次热议看，中国机器人的优势更多体现在第三行和第七行：供应链完整、硬件迭代快、整机成本控制能力强。而模型迭代、数据采集、高自由度运动控制算法，仍是全球范围内的共同挑战，这也是开发者可以切入的机会点。

3. 中国机器人产业的技术版图

热搜词里有大量工业机器人品牌和开发关键词，比如 ABB、发那科、安川、库卡、埃夫特、法奥协作机器人、安川机器人 IO、发那科机器人原点数据变量、ABB 机器人 SDK 控制运动。这些词的密集出现，说明行业关注点不只在炫酷的人形机器人，还在大量存量工业机器人的调试、二次开发与自动化集成。

可以把中国机器人相关产业链分成四类来理解：

3.1 传统工业机器人

以六轴/四轴手臂为主，用于焊接、搬运、喷涂、码垛。国外品牌起步早，控制器、伺服驱动和动力学算法成熟；国内埃斯顿、埃夫特、新时达、汇川等厂商在控制器和伺服层面快速追赶。工程开发中经常要做的工作，包括通过 SDK 读取机器人状态、控制运动、设置 IO 信号，以及处理“原点数据变量”“远程启动 PNS”这类现场问题。

3.2 协作机器人

相对于传统工业机器人，协作机器人更强调安全性、易用性和人机共融。国内代表厂商包括遨博、节卡、越疆、法奥等。开发重点在拖动示教、碰撞检测、力控、视觉引导抓取，以及视觉安全区域设置。

3.3 人形机器人初创公司

优必选、宇树、智元、傅利叶、星动纪元等在这一轮热潮中大量进入公众视野。它们的特点是把“能走、能看、能对话、能操作”作为产品原型目标，硬件迭代很快，甚至开始进入工厂试用。但从软件成熟度来说，开源生态和稳定工具链仍处于早期，大部分功能需要工程团队自己做闭环。

3.4 物流与服务机器人

AMR、无人叉车、配送机器人等，“机器人导航”“机器人定位”关键词主要集中在这一类。SLAM 和路径规划技术相对成熟，通常跑 ROS2 或商业导航框架，配合多机器人调度系统使用。也有不少开发者用开源问答机器人框架配合大模型做交互入口。

从产业角度讲，这轮 Figure 创始人的话之所以让很多人共鸣，是因为中国机器人已经不再是“只做代工”的阶段，而是出现了大量整机设计、量产试产和规模化交付的真实案例。但对工程师来说，硬件能力只是入场券，软件和数据的短板还要花很长时间补。

4. 感知与定位：从传感器到 SLAM 的落地路径

做机器人开发，第一关不是“让它动”，而是“让它知道自己在哪里，看到了什么”。感知与定位属于所有移动机器人项目的地基层。

4.1 传感器选型

移动机器人常用的传感器组合：

4.2 SLAM 方案怎么选

做机器人导航项目，最常见的选型是：

• 室内 2D 导航：优先用 Cartographer，在 ROS1/ROS2 社区都有成熟版本，适合中小型室内场景。
• 视觉/激光融合：LIO-SAM、FAST-LIO 这类 LiDAR-Inertial 方案，适合室外和复杂环境。
• 纯视觉 SLAM：ORB-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 视觉识别与抓取

如果机器人需要执行“识别物体-抓取-放置”这类任务，就需要视觉感知与机械臂协作。通常流程是：

1. RGB-D 相机获取彩色图和深度图。
2. 目标检测模型输出目标框和类别。
3. 深度图对齐后得到目标在相机坐标系下的 3D 位置。
4. 坐标变换到机器人基坐标系下。
5. 控制机械臂运动到抓取点执行抓取。

示例的 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. 仿真先行：机器人仿真平台怎么选

从图中材料看，“机器人仿真平台选择”是很多开发者关注的问题。选型没有唯一答案，关键是匹配项目阶段：

在 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 机器人的核心卖点之一，就是让机器人具备自然语言交互能力。用户说一句“把桌上的红色杯子拿过来”，机器人需要完成语义理解、目标定位、路径规划、抓取决策和运动执行。这个链路被统称为“具身智能”，也是最近两年大模型和机器人交叉方向最火的切入点。

大模型在机器人系统里主要承担两个角色：

• 任务级语义理解：把自然语言指令拆解为子任务序列。
• 感知与动作的端到端映射：VLA（Vision-Language-Action）模型直接输出动作指令或目标位置。

技术路线上，RT-2、PaLM-E、OpenVLA，以及国内多个团队推出的 VLA 模型，都在尝试让机器人直接读取视觉和语言输入，生成低层动作。但真正落地时，还面临几个工程瓶颈：

对于普通开发者，现阶段最实用的做法不是从零训练 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. 常见问题与排查方法

以下问题在机器人项目里出现频率很高，可以按表格思路排查。

排查问题时要养成一个习惯：先确认传感器和通信是否正常，再看算法输出。超过一半的机器人调试时间，花在数据采集、传感器标定和通信链路上，而不是规划算法本身。

11. 总结与下一步

这次 Figure 创始人谈中国机器人引发的热议，最重要的价值不是“谁比谁强”，而是让更多人看到了一个事实：机器人行业的竞争已经从单点算法竞赛，转移到了“硬件供应链 + 软件栈 + 数据闭环 + 量产交付”的综合能力竞赛。中国机器人产业在供应链、整机迭代和成本控制上确实很快，但感知算法、运动控制、高质量数据和稳定工具链仍然是需要持续投入的方向。

如果你是一名开发者和学习者，我最值得一试的路径是：先选一套成熟仿真环境，跑通 ROS2 + SLAM + 导航 + 机械臂运动规划的最小闭环，再逐步加入大模型任务拆解和真实硬件平台。最容易踩的坑是跳过安全和数据验证直接上真机，或者在仿真参数上过度调优，忽略了真实环境里的传感器噪声和通信延迟。

接下来可以重点关注几个方向：开源 VLA 模型和机器人数据集的进展，人形机器人整机成本的下降趋势，以及工业机器人与人形机器人共用技术栈的融合趋势。建议收藏这篇文章，按章节做一份自己的技术清单，边做项目边回来对照。先跑通，再优化，最后再谈超越。