Figure创始人关于中国机器人市场与产业链的一番访谈最近在机器人技术圈里引发热议。很多讨论并没有停留在“谁更强”或“谁会赢”的层面而是迅速落到机器人本体、算法、操作系统、供应链和量产落地这些工程细节上。对开发者来说这其实是一个有价值的信号机器人已经不是实验室里的单一设备而是由感知、决策、控制和交互组成的复杂系统。这里不打算复述访谈内容而是围绕这场讨论中被反复提到的技术点梳理一条从概念到落地的机器人开发主线覆盖ROS2导航、路径规划、工业机器人协议、具身智能和仿真选型等常见问题。读完你可以在自己的项目里按这套框架拆需求、搭环境、跑验证也能在遇到故障时按清单排查。1. 热议背后真正需要讨论的是机器人软件栈1.1 为什么一条访谈会引发机器人圈讨论Figure 是一家专注人形机器人的公司创始人谈到中国机器人时讨论度之所以高核心原因是人形机器人正在从单点 Demo 走向多场景验证。行业内对这类访谈的关注点通常集中在几个方面第一机器人本体是否能稳定运行第二运动控制、导航、感知算法是否能在真实环境中长期工作第三供应链和量产成本是否支撑得起规模化落地。这些话题恰好是开发者平时会遇到的工程问题所以一条商业访谈也会被技术圈拿来当案例拆解。从实际项目角度看机器人并不是一台会动的电脑而是机械结构、电机驱动、传感器、计算单元和操作系统的组合。任何一个环节失效整个系统都会停止。比如导航正常但机械臂抓取不准或者视觉识别正确但运动轨迹抖动最终都表现为整机不可用。因此当行业热议某一个机器人公司时背后通常隐藏着同一个判断这家公司在最难的软件栈和系统集成上做到了什么程度。1.2 开发者高频关注的技术点其实指向同一个问题围绕这场讨论被频繁提到的技术词有很多包括 ROS2 机器人开发、机器人导航、建图与定位、路径规划、多机器人路径规划、工业机器人远程启动、运动学、机器人仿真平台、具身智能、视觉引导机器人等。乍看这些词覆盖的领域很多但放到一起它们其实指向同一个问题机器人系统如何从“能演示”变成“能交付”。“能演示”意味着在受控环境下完成一次动作“能交付”则要求在真实环境中处理不确定性。比如机器人导航在仿真里跑通只说明地图、定位和规划参数在理想模型下可用实物部署还要处理雷达噪声、轮子打滑、地图漂移和动态障碍物。类似的工业机器人远程启动 PNS 只改一个参数可能不会生效因为还依赖外部 IO、安全回路和控制器模式。这些在讨论中被反复提起说明开发者对“从 Demo 到交付”的过程有强烈好奇心也说明机器人开发最大的门槛不是某一个算法而是完整链路的问题。1.3 从单一设备到系统工程的思维转变在传统的嵌入式开发中开发者往往只关注单片机、传感器和执行器在纯算法岗位中开发者又容易只关注模型和训练数据。机器人开发恰好需要把两者结合。当你开始把机器人看成一个系统工程就会理解为什么很多项目要先做仿真再迁移到实物为什么运动学要分成正解和逆解为什么导航模块要区分全局规划与局部规划为什么控制器要同时支持手动、自动和远程三种模式。这种思维转变还体现在调试方式上。单模块调试时你可以直接打印变量机器人系统调试时你却要同时观察话题数据、TF 变换、里程计、地图、状态机、安全信号和控制指令。这也是为什么 ROS2 会在近几年成为机器人开发者的重要工具它提供了一种统一描述和调试机器人系统的方式。2. 机器人系统的层次划分和开发主线2.1 把机器人拆成可交付的五个层次在实际工程里我习惯把机器人系统拆成五个层次机械本体层包括结构件、关节、减速器、末端执行器决定机器人能做什么动作。驱动层包括电机、驱动器、编码器、电流环决定动作是否平滑、是否过载。感知层包括激光雷达、相机、IMU、超声波、力传感器决定机器人是否知道周围环境。决策与规划层包括状态机、运动规划、路径规划、导航、视觉识别和任务调度决定机器人下一步做什么。交互与应用层包括界面、云端 API、语音、灯光、远程控制决定用户如何使用机器人。这五个层次不是孤立的。拿移动机械臂举例机械本体层的末端负载会影响驱动层的最大加速度感知层的相机标定误差会直接进入决策层的坐标计算交互层发来的目标点如果坐标系没有转换决策层即使规划正确也无法执行。机器人开发中大量 Bug 就发生在层次接口上而不是层次内部。2.2 一个简单的分层示例移动底盘 机械臂 视觉假设要做一个服务机器人用移动底盘导航到指定位置再用机械臂抓取桌面物品同时通过灯光反馈系统状态。这个任务在分层后的开发顺序通常是先让底盘在 ROS2 中建图和导航。再让机械臂在固定位置完成正逆运动学验证。接着标定相机和机械臂之间的坐标变换。最后写一个任务状态机把导航、抓取和灯光反馈串起来。如果上来就写一个大状态机一旦导航失败或者抓取偏移会很难定位问题。如果按层次验证每个阶段都可以独立确认输入输出。这也是为什么很多项目会为每个层次建立独立的测试脚本例如在底盘导航时只关心/odom和/amcl_pose不关心机械臂坐标在测试机械臂时只给固定坐标点不启动视觉。2.3 学习环境和生产环境的分层差异学习阶段可以简化用仿真器替代实物用固定点位替代复杂感知。生产阶段则要增加可靠性机械结构要定期标定驱动层要监控电流和温度感知层要处理光照变化和传感器遮挡决策层要有异常恢复交互层要记录日志并支持远程诊断。这里有一个常见误区认为仿真验证过了实物就没问题。事实上仿真中的运动学完美实物却因为安装误差和减速器间隙导致零点偏移仿真中的导航地图干净实物却因为地面反光和临时摆放物品导致定位跳变。因此生产环境必须保留标定流程和故障恢复机制不能依赖“代码不变环境就不变”的假设。3. ROS2 在机器人开发中的位置建图、定位、导航3.1 ROS2 的核心通信模型ROS2 的底层通信基于 DDS节点之间通过话题、服务、动作三种模式交互。话题用于持续的数据流比如激光雷达点云、图像和里程计服务用于一次性的请求响应比如打开灯光动作用于需要持续反馈的任务比如让机器人移动到某个目标点。很多初学者会问 ROS2 的通信协议是不是 UDP。准确地说DDS 在物理层通常使用 UDP默认配置下也是 UDP 传输但 DDS 的可靠通信机制采用确认和重传并不等同于传统 TCP。实际使用中可以在 QoS 里选择可靠或尽力传输。例如/scan点云话题常用 best effort因为丢几帧雷达数据可以接受任务状态机之间则建议用 reliable避免丢失关键指令。如果改成 TCP一般需要写自定义传输配置不推荐在未验证延迟和丢包的情况下直接切换。3.2 用 Nav2 搭一条最小导航链路导航通常分建图、定位、规划三个部分。建图用 SLAM 工具生成地图定位用 AMCL 或 Cartographer 在已知地图中估计机器人位置规划用 Nav2 计算全局路径和局部避障路径。一个最小 Nav2 启动命令可以这样写ros2 launch nav2_bringup bringup_launch.py \ use_sim_time:true \ map:/path/to/map.yaml \ params_file:/path/to/nav2_params.yaml启动后打开 RViz2加载 Nav2 插件用 2D Goal Pose 发布目标点就能看到全局路径和机器人运动。这里最重要的三个配置文件是地图、参数和 URDF。地图决定环境中哪些区域可通行参数决定规划器速度和最小安全距离URDF 决定机器人的 footprint 和传感器 TF。实际开发中许多导航异常不是算法问题而是 footprint 设置和传感器 TF 不对。比如把机器人 footprint 设成 0 半径路径规划会穿过障碍物base_link到laser的 TF 不准确定位会整体偏移。因此导航调试第一步永远是打开 RViz 看数据流而不是直接调参数。3.3 导航不工作时的排查顺序导航不工作时不要先怀疑规划算法。按下面的顺序排查看雷达话题是否有数据ros2 topic echo /scan如果无数据检查驱动和串口权限。看 TF 树是否完整ros2 run tf2_tools view_frames缺少odom或laser说明配置有问题。看定位是否稳定在 RViz 中观察激光点云与地图是否对齐偏差大则重新扫图或调整 AMCL 参数。看代价地图是否更新如果全局代价地图全黑或全绿检查静态地图层和传感器层参数。看规划器输出用 RViz 发布目标点观察 Global Planner 是否生成路径如果卡住考虑增大inflation_radius或修改机器人 footprint。看控制指令ros2 topic echo /cmd_vel如果速度抖动或突然停检查局部规划器的速度限制和加速度限制。3.4 资源受限机器人上如何精简 ROS2在低算力或资源受限机器人上完整启动 Nav2 可能不现实。常见做法有几种一是用精简驱动节点和定时器代替高频话题发布二是用本地状态机配合松耦合传感器三是把 SLAM 放在上位机或云端底盘只运行最小指令节点四是用 TCP 或串口直连方案绕过 ROS2 的中间层。需要注意的是省掉 ROS2 之后建图、定位、路径规划的接口会变成自定义协议必须把时间戳、坐标系和设备唯一 ID 统一好否则后续加功能会很难维护。4. 从路径规划到多机器人协同4.1 单机路径规划的基本算法与适用场景路径规划解决的核心问题是“在有障碍物的环境中找到一条从起点到目标点的可行路径”。经典算法包括 Dijkstra、A*、RRT、RRT* 等。算法特点适用场景Dijkstra广度优先扩展保证最短路径但计算量大小地图、低实时性场景A*加入启发式比 Dijkstra 快保证全局最优栅格地图导航RRT随机采样适合高维空间结果不最优机械臂运动规划RRT*在 RRT 基础上优化路径更平滑空间复杂但预算充足在 ROS2 的 Nav2 里全局规划器常用 NavFn 或 Smac Planner它们本质上是 A* 或其变种。对于服务机器人在二维栅格地图中运行 A* 已经足够对于机械臂需要考虑关节空间的高维路径通常会使用 OMPL 或 MoveIt 调用的 RRT 系列算法。4.2 多机器人路径规划为什么要考虑冲突当多个机器人在同一环境中运行时单机规划就会互相干扰。比如两台 AGV 在窄巷道迎面相遇如果每台都认为自己规划的路径是安全的实际就会相撞或死锁。多机器人路径规划需要在规划阶段就考虑冲突关系常见方案有优先级规划、时间段预留、交通管制法和基于冲突搜索的算法。中文讨论中经常出现“基于改进冲突搜索的多机器人路径规划算法”对应英文里的 Conflict-Based Search (CBS)。CBS 的思路是先为每个机器人独立规划路径再检查路径之间是否有时间或空间冲突如果有冲突就把冲突拆成约束重新规划相关机器人的路径直到所有冲突解除。这个思路比一开始把所有机器人当成一个大状态来搜索高效得多。实现时建议先在小规模地图中验证再扩大到真实项目因为状态空间会随机器人数量指数增长。4.3 规划参数调整与常见坑调整路径规划时最容易踩的坑有三个把全局路径长度当作唯一目标。实际移动中频繁转弯和急停会让机器人耗电增加、乘客不舒服因此要加入转角成本和平滑成本。忽略机器人本身的运动学约束。对差速底盘路径可以任意经过栅格对阿克曼底盘必须限制最小转弯半径否则局部规划器跟不上。在动态环境中只依赖全局规划。全局地图更新慢动态障碍物要靠局部规划器处理否则机器人会频繁阻塞。推荐做法是把规划器参数放到配置文件中用仿真批量测试不同密度障碍物场景再在实物环境中用同一组参数跑回归。5. 工业机器人和人形机器人是两条互补的技术线5.1 工业机器人生态FANUC、ABB、KUKA、安川人形机器人讨论度高的同时工业机器人依然是机器人领域最大的落地场景。FANUC、ABB、KUKA、安川等品牌在中国市场都有大量部署很多开发者既做 ROS2 机器人也要维护生产线上的工业机械臂。两者技术栈差异不小工业机器人强调重复定位精度、安全回路、示教器和 PLC 集成人形机器人强调感知、平衡、全身控制和 AI 决策。但对开发者来说了解工业机器人的协议和调用方式仍然重要。品牌编程方式远程控制常见方式FANUCTP 程序 / KARELPNS 远程启动、以太网 FANUC iPCABBRAPID 程序RobotStudio、PC SDK、UGSKUKAKRL 程序KUKA Ethernet KRL XML安川INFORM 程序MotoPlus、IO 控制、上位机以太网5.2 FANUC 的 PNS 远程启动与寄存器参数在产线集成中FANUC 机器人远程启动 PNS 是很常见的问题。PNSProgram Number Select是 FANUC 提供的一种外部启动方式PLC 或上位机选择程序编号机器人控制器启动对应的程序。常见配置步骤如下在控制器上启用程序选择功能通常需要确认外部控制相关使能位。确认控制器处于远程自动模式而不是手动模式。用外部 IO 或 PLC 程序写入要启动的程序编号。给启动命令一个持续的脉冲或电平触发机器人开始运行。另一个高频问题是$SBR[n].$PARAM[47]这类寄存器参数。FANUC 的 SBR 是子程序或后台程序$PARAM是整型参数数组可以在不同程序之间传递数值。常见用途是把测试参数从主程序传入子程序比如次数、速度倍率或工装编号。修改$PARAM前要先确认它被哪个程序读取避免改完以后后续程序拿到了错误数据。5.3 ABB 手动速度和自动速度的关系关于“ABB 机器人手动速度为 15自动后的速度会是 15 吗”答案是否定的。ABB 机器人手动模式的最大速度一般会被安全限制在一个较低值通常是 250 mm/s 或更低目的在于保护示教人员。手动速度倍率 15 表示当前操作速度的百分比不影响自动运行。自动速度由 RAPID 程序中的运动指令如 MoveL v500和当前自动速度倍率共同决定。也就是说手动条件下设置的 15 只是操作杆的速率自动运行时会使用程序里的目标速度并乘以操作屏上的自动倍率。要确认实际自动速度应检查指令中的速度值和倍率而不是看手动速度。5.4 KUKA 的 KRL 循环与安川 IOKUKA 的编程语言是 KRL在大批量产线信号交互中WHILE TRUE常用于循环等待外部信号例如WHILE $IN_DIG[1] FALSE DO ENDWHILE这段程序会一直等待数字输入 1 变为 TRUE再继续执行。KRL 的循环和条件控制与通用语言类似但要注意程序按键、停止状态和中断策略会影响循环执行必须考虑急停和暂停后的恢复逻辑。安川机器人使用 INFORM 语言IO 分为专用 IO、通用 IO 和内部继电器。开发者可以通过控制柜上的端子、通讯扩展板或设备程序读取外部信号。安川 IO 的地址映射需要先查看控制柜内分配表再在程序中引用。常见的坑是地址编号写错导致信号始终为 0 或始终为 1排查时要先看 IO 监控画面确认信号实际状态。5.5 安全标准与远程启动生产注意点工业机器人远程启动并不是单纯发一个指令。根据 ISO 10218 等标准自动模式启动要满足安全条件包括安全门关闭、区域扫描正常、急停复位、工作区无人或已设置安全防护。生产环境中远程启动失败首先要检查安全回路状态而不是程序逻辑。对于需要与 PLC 联动的项目建议把启动条件、程序号、完成信号、故障信号都写入状态字方便上位机判断当前状态。同时要保留手动模式下的单步步进功能便于故障恢复。6. 具身智能把感知、理解、执行串起来6.1 从运动控制到具身智能“具身智能”是对机器人系统的更高要求机器人不仅要有运动能力还要理解环境、任务和人的意图。它强调感知、决策、执行的闭环。典型的具身智能任务包括机器人看到桌面上的杯子理解“把杯子放到托盘里”的指令规划抓取姿态执行抓取并移动到目标位置同时反馈是否完成。这套流程在传统机器人里也能做只是每个环节由固定规则控制。具身智能希望引入视觉语言模型、强化学习和更多泛化能力让机器人应对未知物体和未定义环境。对工程而言引入大模型不等于替换掉运动控制和导航而是在决策层增加一个自然语言与视觉理解的接口。6.2 环境感知、导航和灯光交互的落地组合“服务机器人环境感知灯光交互系统开发”是一个很适合入门的具身智能项目。思路是机器人通过摄像头或激光雷达感知是否有人进入区域再根据状态控制灯光颜色比如待机时蓝色、工作时绿色、异常时红色。感知部分可以用简单的人体检测或占用检测交互部分用灯光反馈即可。这类项目不需要强大的大模型却能把感知、决策、执行、反馈四个环节完整串起来。开发时建议先定义状态机再定义灯光映射最后定义感知事件到状态的转换条件。例如“有人靠近”触发“接待状态”持续 5 秒无人则回到“待机状态”。状态转换要加延时和去抖避免频繁切换。6.3 让机器人与大模型对话边缘问答方案具身智能的下一步往往是把自然语言接入机器人。常见的方案包括用 Ollama 搭配开源问答机器人 Web 服务。在资源允许的边缘设备或小服务器上可以部署轻量级大模型通过 WebSocket 或 HTTP 与机器人通信。机器人的语音识别模块把用户问题转成文本发送给大模型服务大模型返回回答或指令再由机器人的执行模块完成操作。这里要注意大模型输出并不稳定不能直接把输出作为机器人控制指令。推荐做法是要求大模型输出结构化 JSON再由机器人端的解析器校验指令字段和参数范围。例如{ action: navigate, target: table, speed: 0.3 }如果解析失败或参数超出限定范围就忽略并提示重新表达。同时要设置超时和降级策略保证大模型服务不可用时机器人仍能执行预置安全动作。6.4 TVA 视觉引导与运动规划的接口问题视觉引导是工业具身智能的重要组成。面向产线时TVA 视觉引导机器人这类方案的核心问题是把相机识别到的物体坐标转换到机器人坐标系。工程上至少需要四步相机内参标定、手眼标定、物体识别、坐标发布。如果物体中心坐标在相机坐标系下是(x, y, z)但机器人基坐标系和相机坐标系没有对齐机械臂就会抓空。因此视觉引导项目的验收标准不只是识别准确率更要看坐标变换误差。推荐在每次运行前用固定标志点验证标定发现偏移超过阈值就重新标定。不要认为标定一次可以永久使用温度和振动都会改变相机安装位置。7. 仿真平台选型在电脑里先把机器人跑通7.1 主流仿真平台对比仿真能降低调试成本也能让人在没有实体机器人时先完成算法验证。“机器人仿真平台选择”是很多新人都会遇到的问题。主流平台对比如下平台特点适用场景学习成本GazeboROS 集成成熟社区资料多基础导航、机械臂仿真中Webots物理引擎较好支持多种机器人教学、原型验证中Isaac Sim基于 NVIDIAGPU 加速适合具身智能大模型、强化学习、多传感器仿真高MuJoCo快速物理仿真适合强化学习运动控制、RL 训练中RViz不是仿真是数据可视化工具查看话题、TF、路径低没有绝对最好的仿真平台。如果你主要做 ROS2 导航Gazebo 很合适如果你做人形机器人和强化学习MuJoCo 或 Isaac Sim 更高效如果你只是看数据流RViz 就够了。7.2 从 URDF 到导航仿真的最小流程一个典型的仿真流程是先用 URDF 描述机器人模型然后加载到 Gazebo 或 Webots接着发布雷达和里程计数据再运行 SLAM 或 Nav2。URDF 中最重要的内容是 link 和 joint例如link namebase_link inertial.../inertial visual.../visual collision.../collision /link joint namebase_to_laser typefixed parent linkbase_link/ child linklaser/ origin xyz0 0 0.3 rpy 机器人系统开发主线：从ROS2导航到具身智能仿真
Figure创始人关于中国机器人市场与产业链的一番访谈最近在机器人技术圈里引发热议。很多讨论并没有停留在“谁更强”或“谁会赢”的层面而是迅速落到机器人本体、算法、操作系统、供应链和量产落地这些工程细节上。对开发者来说这其实是一个有价值的信号机器人已经不是实验室里的单一设备而是由感知、决策、控制和交互组成的复杂系统。这里不打算复述访谈内容而是围绕这场讨论中被反复提到的技术点梳理一条从概念到落地的机器人开发主线覆盖ROS2导航、路径规划、工业机器人协议、具身智能和仿真选型等常见问题。读完你可以在自己的项目里按这套框架拆需求、搭环境、跑验证也能在遇到故障时按清单排查。1. 热议背后真正需要讨论的是机器人软件栈1.1 为什么一条访谈会引发机器人圈讨论Figure 是一家专注人形机器人的公司创始人谈到中国机器人时讨论度之所以高核心原因是人形机器人正在从单点 Demo 走向多场景验证。行业内对这类访谈的关注点通常集中在几个方面第一机器人本体是否能稳定运行第二运动控制、导航、感知算法是否能在真实环境中长期工作第三供应链和量产成本是否支撑得起规模化落地。这些话题恰好是开发者平时会遇到的工程问题所以一条商业访谈也会被技术圈拿来当案例拆解。从实际项目角度看机器人并不是一台会动的电脑而是机械结构、电机驱动、传感器、计算单元和操作系统的组合。任何一个环节失效整个系统都会停止。比如导航正常但机械臂抓取不准或者视觉识别正确但运动轨迹抖动最终都表现为整机不可用。因此当行业热议某一个机器人公司时背后通常隐藏着同一个判断这家公司在最难的软件栈和系统集成上做到了什么程度。1.2 开发者高频关注的技术点其实指向同一个问题围绕这场讨论被频繁提到的技术词有很多包括 ROS2 机器人开发、机器人导航、建图与定位、路径规划、多机器人路径规划、工业机器人远程启动、运动学、机器人仿真平台、具身智能、视觉引导机器人等。乍看这些词覆盖的领域很多但放到一起它们其实指向同一个问题机器人系统如何从“能演示”变成“能交付”。“能演示”意味着在受控环境下完成一次动作“能交付”则要求在真实环境中处理不确定性。比如机器人导航在仿真里跑通只说明地图、定位和规划参数在理想模型下可用实物部署还要处理雷达噪声、轮子打滑、地图漂移和动态障碍物。类似的工业机器人远程启动 PNS 只改一个参数可能不会生效因为还依赖外部 IO、安全回路和控制器模式。这些在讨论中被反复提起说明开发者对“从 Demo 到交付”的过程有强烈好奇心也说明机器人开发最大的门槛不是某一个算法而是完整链路的问题。1.3 从单一设备到系统工程的思维转变在传统的嵌入式开发中开发者往往只关注单片机、传感器和执行器在纯算法岗位中开发者又容易只关注模型和训练数据。机器人开发恰好需要把两者结合。当你开始把机器人看成一个系统工程就会理解为什么很多项目要先做仿真再迁移到实物为什么运动学要分成正解和逆解为什么导航模块要区分全局规划与局部规划为什么控制器要同时支持手动、自动和远程三种模式。这种思维转变还体现在调试方式上。单模块调试时你可以直接打印变量机器人系统调试时你却要同时观察话题数据、TF 变换、里程计、地图、状态机、安全信号和控制指令。这也是为什么 ROS2 会在近几年成为机器人开发者的重要工具它提供了一种统一描述和调试机器人系统的方式。2. 机器人系统的层次划分和开发主线2.1 把机器人拆成可交付的五个层次在实际工程里我习惯把机器人系统拆成五个层次机械本体层包括结构件、关节、减速器、末端执行器决定机器人能做什么动作。驱动层包括电机、驱动器、编码器、电流环决定动作是否平滑、是否过载。感知层包括激光雷达、相机、IMU、超声波、力传感器决定机器人是否知道周围环境。决策与规划层包括状态机、运动规划、路径规划、导航、视觉识别和任务调度决定机器人下一步做什么。交互与应用层包括界面、云端 API、语音、灯光、远程控制决定用户如何使用机器人。这五个层次不是孤立的。拿移动机械臂举例机械本体层的末端负载会影响驱动层的最大加速度感知层的相机标定误差会直接进入决策层的坐标计算交互层发来的目标点如果坐标系没有转换决策层即使规划正确也无法执行。机器人开发中大量 Bug 就发生在层次接口上而不是层次内部。2.2 一个简单的分层示例移动底盘 机械臂 视觉假设要做一个服务机器人用移动底盘导航到指定位置再用机械臂抓取桌面物品同时通过灯光反馈系统状态。这个任务在分层后的开发顺序通常是先让底盘在 ROS2 中建图和导航。再让机械臂在固定位置完成正逆运动学验证。接着标定相机和机械臂之间的坐标变换。最后写一个任务状态机把导航、抓取和灯光反馈串起来。如果上来就写一个大状态机一旦导航失败或者抓取偏移会很难定位问题。如果按层次验证每个阶段都可以独立确认输入输出。这也是为什么很多项目会为每个层次建立独立的测试脚本例如在底盘导航时只关心/odom和/amcl_pose不关心机械臂坐标在测试机械臂时只给固定坐标点不启动视觉。2.3 学习环境和生产环境的分层差异学习阶段可以简化用仿真器替代实物用固定点位替代复杂感知。生产阶段则要增加可靠性机械结构要定期标定驱动层要监控电流和温度感知层要处理光照变化和传感器遮挡决策层要有异常恢复交互层要记录日志并支持远程诊断。这里有一个常见误区认为仿真验证过了实物就没问题。事实上仿真中的运动学完美实物却因为安装误差和减速器间隙导致零点偏移仿真中的导航地图干净实物却因为地面反光和临时摆放物品导致定位跳变。因此生产环境必须保留标定流程和故障恢复机制不能依赖“代码不变环境就不变”的假设。3. ROS2 在机器人开发中的位置建图、定位、导航3.1 ROS2 的核心通信模型ROS2 的底层通信基于 DDS节点之间通过话题、服务、动作三种模式交互。话题用于持续的数据流比如激光雷达点云、图像和里程计服务用于一次性的请求响应比如打开灯光动作用于需要持续反馈的任务比如让机器人移动到某个目标点。很多初学者会问 ROS2 的通信协议是不是 UDP。准确地说DDS 在物理层通常使用 UDP默认配置下也是 UDP 传输但 DDS 的可靠通信机制采用确认和重传并不等同于传统 TCP。实际使用中可以在 QoS 里选择可靠或尽力传输。例如/scan点云话题常用 best effort因为丢几帧雷达数据可以接受任务状态机之间则建议用 reliable避免丢失关键指令。如果改成 TCP一般需要写自定义传输配置不推荐在未验证延迟和丢包的情况下直接切换。3.2 用 Nav2 搭一条最小导航链路导航通常分建图、定位、规划三个部分。建图用 SLAM 工具生成地图定位用 AMCL 或 Cartographer 在已知地图中估计机器人位置规划用 Nav2 计算全局路径和局部避障路径。一个最小 Nav2 启动命令可以这样写ros2 launch nav2_bringup bringup_launch.py \ use_sim_time:true \ map:/path/to/map.yaml \ params_file:/path/to/nav2_params.yaml启动后打开 RViz2加载 Nav2 插件用 2D Goal Pose 发布目标点就能看到全局路径和机器人运动。这里最重要的三个配置文件是地图、参数和 URDF。地图决定环境中哪些区域可通行参数决定规划器速度和最小安全距离URDF 决定机器人的 footprint 和传感器 TF。实际开发中许多导航异常不是算法问题而是 footprint 设置和传感器 TF 不对。比如把机器人 footprint 设成 0 半径路径规划会穿过障碍物base_link到laser的 TF 不准确定位会整体偏移。因此导航调试第一步永远是打开 RViz 看数据流而不是直接调参数。3.3 导航不工作时的排查顺序导航不工作时不要先怀疑规划算法。按下面的顺序排查看雷达话题是否有数据ros2 topic echo /scan如果无数据检查驱动和串口权限。看 TF 树是否完整ros2 run tf2_tools view_frames缺少odom或laser说明配置有问题。看定位是否稳定在 RViz 中观察激光点云与地图是否对齐偏差大则重新扫图或调整 AMCL 参数。看代价地图是否更新如果全局代价地图全黑或全绿检查静态地图层和传感器层参数。看规划器输出用 RViz 发布目标点观察 Global Planner 是否生成路径如果卡住考虑增大inflation_radius或修改机器人 footprint。看控制指令ros2 topic echo /cmd_vel如果速度抖动或突然停检查局部规划器的速度限制和加速度限制。3.4 资源受限机器人上如何精简 ROS2在低算力或资源受限机器人上完整启动 Nav2 可能不现实。常见做法有几种一是用精简驱动节点和定时器代替高频话题发布二是用本地状态机配合松耦合传感器三是把 SLAM 放在上位机或云端底盘只运行最小指令节点四是用 TCP 或串口直连方案绕过 ROS2 的中间层。需要注意的是省掉 ROS2 之后建图、定位、路径规划的接口会变成自定义协议必须把时间戳、坐标系和设备唯一 ID 统一好否则后续加功能会很难维护。4. 从路径规划到多机器人协同4.1 单机路径规划的基本算法与适用场景路径规划解决的核心问题是“在有障碍物的环境中找到一条从起点到目标点的可行路径”。经典算法包括 Dijkstra、A*、RRT、RRT* 等。算法特点适用场景Dijkstra广度优先扩展保证最短路径但计算量大小地图、低实时性场景A*加入启发式比 Dijkstra 快保证全局最优栅格地图导航RRT随机采样适合高维空间结果不最优机械臂运动规划RRT*在 RRT 基础上优化路径更平滑空间复杂但预算充足在 ROS2 的 Nav2 里全局规划器常用 NavFn 或 Smac Planner它们本质上是 A* 或其变种。对于服务机器人在二维栅格地图中运行 A* 已经足够对于机械臂需要考虑关节空间的高维路径通常会使用 OMPL 或 MoveIt 调用的 RRT 系列算法。4.2 多机器人路径规划为什么要考虑冲突当多个机器人在同一环境中运行时单机规划就会互相干扰。比如两台 AGV 在窄巷道迎面相遇如果每台都认为自己规划的路径是安全的实际就会相撞或死锁。多机器人路径规划需要在规划阶段就考虑冲突关系常见方案有优先级规划、时间段预留、交通管制法和基于冲突搜索的算法。中文讨论中经常出现“基于改进冲突搜索的多机器人路径规划算法”对应英文里的 Conflict-Based Search (CBS)。CBS 的思路是先为每个机器人独立规划路径再检查路径之间是否有时间或空间冲突如果有冲突就把冲突拆成约束重新规划相关机器人的路径直到所有冲突解除。这个思路比一开始把所有机器人当成一个大状态来搜索高效得多。实现时建议先在小规模地图中验证再扩大到真实项目因为状态空间会随机器人数量指数增长。4.3 规划参数调整与常见坑调整路径规划时最容易踩的坑有三个把全局路径长度当作唯一目标。实际移动中频繁转弯和急停会让机器人耗电增加、乘客不舒服因此要加入转角成本和平滑成本。忽略机器人本身的运动学约束。对差速底盘路径可以任意经过栅格对阿克曼底盘必须限制最小转弯半径否则局部规划器跟不上。在动态环境中只依赖全局规划。全局地图更新慢动态障碍物要靠局部规划器处理否则机器人会频繁阻塞。推荐做法是把规划器参数放到配置文件中用仿真批量测试不同密度障碍物场景再在实物环境中用同一组参数跑回归。5. 工业机器人和人形机器人是两条互补的技术线5.1 工业机器人生态FANUC、ABB、KUKA、安川人形机器人讨论度高的同时工业机器人依然是机器人领域最大的落地场景。FANUC、ABB、KUKA、安川等品牌在中国市场都有大量部署很多开发者既做 ROS2 机器人也要维护生产线上的工业机械臂。两者技术栈差异不小工业机器人强调重复定位精度、安全回路、示教器和 PLC 集成人形机器人强调感知、平衡、全身控制和 AI 决策。但对开发者来说了解工业机器人的协议和调用方式仍然重要。品牌编程方式远程控制常见方式FANUCTP 程序 / KARELPNS 远程启动、以太网 FANUC iPCABBRAPID 程序RobotStudio、PC SDK、UGSKUKAKRL 程序KUKA Ethernet KRL XML安川INFORM 程序MotoPlus、IO 控制、上位机以太网5.2 FANUC 的 PNS 远程启动与寄存器参数在产线集成中FANUC 机器人远程启动 PNS 是很常见的问题。PNSProgram Number Select是 FANUC 提供的一种外部启动方式PLC 或上位机选择程序编号机器人控制器启动对应的程序。常见配置步骤如下在控制器上启用程序选择功能通常需要确认外部控制相关使能位。确认控制器处于远程自动模式而不是手动模式。用外部 IO 或 PLC 程序写入要启动的程序编号。给启动命令一个持续的脉冲或电平触发机器人开始运行。另一个高频问题是$SBR[n].$PARAM[47]这类寄存器参数。FANUC 的 SBR 是子程序或后台程序$PARAM是整型参数数组可以在不同程序之间传递数值。常见用途是把测试参数从主程序传入子程序比如次数、速度倍率或工装编号。修改$PARAM前要先确认它被哪个程序读取避免改完以后后续程序拿到了错误数据。5.3 ABB 手动速度和自动速度的关系关于“ABB 机器人手动速度为 15自动后的速度会是 15 吗”答案是否定的。ABB 机器人手动模式的最大速度一般会被安全限制在一个较低值通常是 250 mm/s 或更低目的在于保护示教人员。手动速度倍率 15 表示当前操作速度的百分比不影响自动运行。自动速度由 RAPID 程序中的运动指令如 MoveL v500和当前自动速度倍率共同决定。也就是说手动条件下设置的 15 只是操作杆的速率自动运行时会使用程序里的目标速度并乘以操作屏上的自动倍率。要确认实际自动速度应检查指令中的速度值和倍率而不是看手动速度。5.4 KUKA 的 KRL 循环与安川 IOKUKA 的编程语言是 KRL在大批量产线信号交互中WHILE TRUE常用于循环等待外部信号例如WHILE $IN_DIG[1] FALSE DO ENDWHILE这段程序会一直等待数字输入 1 变为 TRUE再继续执行。KRL 的循环和条件控制与通用语言类似但要注意程序按键、停止状态和中断策略会影响循环执行必须考虑急停和暂停后的恢复逻辑。安川机器人使用 INFORM 语言IO 分为专用 IO、通用 IO 和内部继电器。开发者可以通过控制柜上的端子、通讯扩展板或设备程序读取外部信号。安川 IO 的地址映射需要先查看控制柜内分配表再在程序中引用。常见的坑是地址编号写错导致信号始终为 0 或始终为 1排查时要先看 IO 监控画面确认信号实际状态。5.5 安全标准与远程启动生产注意点工业机器人远程启动并不是单纯发一个指令。根据 ISO 10218 等标准自动模式启动要满足安全条件包括安全门关闭、区域扫描正常、急停复位、工作区无人或已设置安全防护。生产环境中远程启动失败首先要检查安全回路状态而不是程序逻辑。对于需要与 PLC 联动的项目建议把启动条件、程序号、完成信号、故障信号都写入状态字方便上位机判断当前状态。同时要保留手动模式下的单步步进功能便于故障恢复。6. 具身智能把感知、理解、执行串起来6.1 从运动控制到具身智能“具身智能”是对机器人系统的更高要求机器人不仅要有运动能力还要理解环境、任务和人的意图。它强调感知、决策、执行的闭环。典型的具身智能任务包括机器人看到桌面上的杯子理解“把杯子放到托盘里”的指令规划抓取姿态执行抓取并移动到目标位置同时反馈是否完成。这套流程在传统机器人里也能做只是每个环节由固定规则控制。具身智能希望引入视觉语言模型、强化学习和更多泛化能力让机器人应对未知物体和未定义环境。对工程而言引入大模型不等于替换掉运动控制和导航而是在决策层增加一个自然语言与视觉理解的接口。6.2 环境感知、导航和灯光交互的落地组合“服务机器人环境感知灯光交互系统开发”是一个很适合入门的具身智能项目。思路是机器人通过摄像头或激光雷达感知是否有人进入区域再根据状态控制灯光颜色比如待机时蓝色、工作时绿色、异常时红色。感知部分可以用简单的人体检测或占用检测交互部分用灯光反馈即可。这类项目不需要强大的大模型却能把感知、决策、执行、反馈四个环节完整串起来。开发时建议先定义状态机再定义灯光映射最后定义感知事件到状态的转换条件。例如“有人靠近”触发“接待状态”持续 5 秒无人则回到“待机状态”。状态转换要加延时和去抖避免频繁切换。6.3 让机器人与大模型对话边缘问答方案具身智能的下一步往往是把自然语言接入机器人。常见的方案包括用 Ollama 搭配开源问答机器人 Web 服务。在资源允许的边缘设备或小服务器上可以部署轻量级大模型通过 WebSocket 或 HTTP 与机器人通信。机器人的语音识别模块把用户问题转成文本发送给大模型服务大模型返回回答或指令再由机器人的执行模块完成操作。这里要注意大模型输出并不稳定不能直接把输出作为机器人控制指令。推荐做法是要求大模型输出结构化 JSON再由机器人端的解析器校验指令字段和参数范围。例如{ action: navigate, target: table, speed: 0.3 }如果解析失败或参数超出限定范围就忽略并提示重新表达。同时要设置超时和降级策略保证大模型服务不可用时机器人仍能执行预置安全动作。6.4 TVA 视觉引导与运动规划的接口问题视觉引导是工业具身智能的重要组成。面向产线时TVA 视觉引导机器人这类方案的核心问题是把相机识别到的物体坐标转换到机器人坐标系。工程上至少需要四步相机内参标定、手眼标定、物体识别、坐标发布。如果物体中心坐标在相机坐标系下是(x, y, z)但机器人基坐标系和相机坐标系没有对齐机械臂就会抓空。因此视觉引导项目的验收标准不只是识别准确率更要看坐标变换误差。推荐在每次运行前用固定标志点验证标定发现偏移超过阈值就重新标定。不要认为标定一次可以永久使用温度和振动都会改变相机安装位置。7. 仿真平台选型在电脑里先把机器人跑通7.1 主流仿真平台对比仿真能降低调试成本也能让人在没有实体机器人时先完成算法验证。“机器人仿真平台选择”是很多新人都会遇到的问题。主流平台对比如下平台特点适用场景学习成本GazeboROS 集成成熟社区资料多基础导航、机械臂仿真中Webots物理引擎较好支持多种机器人教学、原型验证中Isaac Sim基于 NVIDIAGPU 加速适合具身智能大模型、强化学习、多传感器仿真高MuJoCo快速物理仿真适合强化学习运动控制、RL 训练中RViz不是仿真是数据可视化工具查看话题、TF、路径低没有绝对最好的仿真平台。如果你主要做 ROS2 导航Gazebo 很合适如果你做人形机器人和强化学习MuJoCo 或 Isaac Sim 更高效如果你只是看数据流RViz 就够了。7.2 从 URDF 到导航仿真的最小流程一个典型的仿真流程是先用 URDF 描述机器人模型然后加载到 Gazebo 或 Webots接着发布雷达和里程计数据再运行 SLAM 或 Nav2。URDF 中最重要的内容是 link 和 joint例如link namebase_link inertial.../inertial visual.../visual collision.../collision /link joint namebase_to_laser typefixed parent linkbase_link/ child linklaser/ origin xyz0 0 0.3 rpy