公开报道里具身智能机器人走进连锁商超已经不算新闻。真正值得关注的是当机器人从演示展台进入真实货架通道从单台样机变成多台常态化运营它要跨越的工程问题远比模型效果更复杂。商超场景有密集货架、行人、购物车、金属推车、玻璃反光、临期促销堆头地面材质从瓷砖到地垫不断变化灯光和人群遮挡也会随时改变传感器的输入。这些环境特征决定了具身智能机器人不能只靠一个大模型跑通流程而是需要环境感知、自主导航、机械臂操作、多机调度、数据闭环和远程运维共同构成的完整系统。这篇文章从工程落地视角拆解具身智能机器人在商超零售场景从单机演示走向规模化运营时必须优先解决的几类问题。内容包括传感器标定、动态建图、导航避障、抓取操作、多机调度、数据回流和线上运维并给出示例代码、配置片段、参数说明和排错清单。读者可以把它当作一份技术路线参考也可以直接用于评估自己的机器人项目离规模化落地还差哪些环节。1. 商超场景下具身智能机器人要解决的真实问题1.1 为什么商超是具身智能落地的典型场景商超环境对具身智能机器人来说属于“中等结构化场景”。它不像工厂产线那样有完全固定的工位和夹具也不像完全开放的家庭环境那样毫无规律。货架位置相对稳定商品种类可枚举地面通道有明确宽度但这些结构会在运营过程中不断调整促销堆头会临时出现货架会补充商品购物车和行人会阻塞通道。正是这种“有一定规则但规则随时变化”的特征让商超成为测试具身智能能力的合适场地。机器人不能只记住一张静态地图也不能完全依赖深度强化学习从头探索。它需要在先验地图基础上实时感知动态变化并决定什么时候绕行、什么时候等待、什么时候请求人工介入。从商业价值看商超中的补货、盘点、引导、清洁、价格校验等任务重复度高且人力成本明显。机器人如果能稳定完成其中一项就能产生可计算的价值。这也解释了为什么公开报道中机器人在商超场景落地时通常会先选一个足够窄、足够清晰的任务切片比如夜间盘点或小件商品补货而不是一开始就要求它像店员一样处理所有事情。1.2 从“能走”到“能干”具身智能的三大能力闭环具身智能机器人要完成商超任务表面上是“会走”和“会抓”实际上需要三个能力闭环配合。第一是环境感知回答“我在哪里、周围有什么”。机器人要通过激光雷达、相机、IMU、轮式里程计等传感器建立对自身位置和外部环境的实时理解。第二是自主移动回答“如何安全到达目标位置”。机器人需要在货架通道、人群、购物车之间规划路径并在执行过程中不断修正避免碰撞和阻塞。第三是操作执行回答“到了目标位置之后怎么完成任务”。机械臂需要识别商品、估计位姿、规划抓取轨迹并在力控约束下完成拿取和摆放。这三个能力不是串联关系。机械臂抓取前移动平台必须停在合适的作业位姿移动导航过程中感知系统必须持续工作而感知错误会同时影响导航和操作。很多项目在 Demo 阶段能跑通是因为演示场景预先限制了光照、障碍和任务类型一旦进入真实商超三个环节之间的接口问题就会集中爆发。1.3 规模化落地不等于单机演示多机协作与系统治理单台机器人在商超跑通一个演示任务和十台机器人同时在线运营是完全不同的工程复杂度。单机demo只需要保证“这台机器在这段时间内不出错”规模化运营需要保证“整个系统在持续运行中可监控、可恢复、可升级”。规模化带来的问题包括多台机器人如何共享地图、如何避免争抢同一通道和充电桩任务如何拆解、分配、追踪和超时重试机器人离线或卡死后如何告警、远程恢复或人工接管软件更新如何灰度发布避免一次升级导致全域故障。这些问题单靠改进某一个模型无法解决。它们属于系统架构、调度算法、运维体系和数据基础设施的范畴。这也是本文后续章节按“感知、导航、操作、调度、数据运维”展开的原因具身智能落地商超真正考验的是工程系统而不是单一模型精度。2. 环境感知与建模让机器人在拥挤货架间不迷路2.1 传感器组合与安装位置感知方案首先要确定传感器组合。商超环境常见的组合是“激光雷达 RGB-D 相机 IMU 轮式里程计”不同传感器承担不同角色。传感器主要作用常见选型需要注意的问题2D/3D 激光雷达建图、定位、障碍检测单线或多线雷达货架底部空隙会造成扫描穿透需配合阈值过滤RGB-D 相机商品识别、抓取位姿估计、近距离避障结构光或 ToF 相机玻璃、反光表面和强光下深度数据会失效IMU运动估计、位姿插值六轴或九轴惯性单元长时间积分会漂移不能单独依赖轮式里程计短时间运动推算电机编码器打滑场景下会失真需要和激光匹配校正传感器安装位置直接影响感知效果。激光雷达通常安装在机器人中部或顶部避免被货架和人体遮挡RGB-D 相机如果用于抓取要安装在机械臂末端附近或能覆盖作业区域的位置如果用于导航避障应安装在底盘前方并稍微下倾保证能看到低矮障碍物和儿童高度区域。常见问题是把相机装得过高或过平导致近处地面和低矮货架层不可见。验证方法很简单在机器人的目标作业高度摆放一个纸箱分别在静止和缓慢移动状态下查看点云或深度图确认目标区域能被完整覆盖。2.2 动态环境中的建图与定位问题商超里的“地图”并不是一成不变的。货架补货后商品外包装会突出促销堆头会临时改变通道宽度顾客会停留、转身、放下购物车。如果机器人只依赖一张静态高精地图做定位一旦环境发生局部变化匹配分数就会下降定位结果可能出现跳变。工程上的常用做法是分层地图管理全局静态地图用于全局定位和路径规划更新频率低由运维人员确认后发布。局部代价地图由机器人实时构建叠加激光点云和深度数据用于局部避障。语义图层标注充电桩、装卸区、货架区域、禁行区域用于任务调度和交互决策。定位算法方面常见的 2D 激光定位方案是 AMCL自适应蒙特卡洛定位。它通过粒子滤波估计机器人在地图中的位置。在商超这种动态场景AMCL 容易受到行人和临时障碍物影响。建议做法是使用“静态地图匹配 动态障碍物单独检测”的方式定位输入只使用地面附近相对稳定的激光点动态障碍物交给局部代价地图处理而不是让动态点参与全局定位。2.3 手眼标定与坐标系检查示例机械臂抓取前必须确认相机坐标系、机械臂基座坐标系、机器人底盘坐标系之间的变换关系。这个环节叫手眼标定。手眼标定分为“眼在手上”和“眼在手外”两种商超机器人通常使用“眼在手上”或车体固定相机与机械臂联合标定的方案。使用常见工具链时可以参考下面的标定流程。具体命令会随 ROS 版本和标定工具版本变化落地前要先确认依赖版本。# ROS 2 环境下使用 easy_handeye2 的通用执行流程 # 第一步启动机械臂和相机驱动 ros2 launch robot_bringup robot.launch.py # 第二步启动标定程序生成采样指令 ros2 launch easy_handeye2 calibrate.launch.py标定过程中要注意三个检查点机械臂末端执行器在不同姿态下标定板都能被相机完整看到。每次采样时机械臂位姿差异要足够大不能只在同一个姿态附近微调。标定完成后要保存变换矩阵并在真实场景中做一次验证抓取而不是只看重投影误差。最容易被忽略的是 TF 树检查。启动系统后用下面的方式查看坐标系关系是否完整ros2 run tf2_ros tf2_echo map odom ros2 run tf2_ros tf2_echo odom base_link ros2 run tf2_ros tf2_echo camera_link tool0如果某个坐标系连接缺失导航和抓取会在运行时报出“Could not find transform”类错误。多数情况下不是算法问题而是标定文件没有加载或 TF 发布节点没有启动。2.4 验证感知链路录包、回放、看数据传感器和标定完成后不要急着跑导航先做一次数据链路验证。推荐做法是录制 rosbag再离线回放。# 记录关键话题 ros2 bag record -o scene_test \ /scan \ /camera/depth/color/points \ /camera/color/image_raw \ /odom \ /tf \ /tf_static回放时使用 RViz 订阅对应话题检查三件事点云是否存在大块空洞TF 变换是否稳定地图中的静态障碍物是否出现在正确位置。如果点云在玻璃门、镜面货架附近出现明显空洞说明深度相机在这个场景下不可靠需要补充激光数据或调整作业路线。注意不要只验证“程序能启动”还要验证传感器时间戳是否同步、话题频率是否稳定、坐标系是否完整。商超机器人很多的“偶发定位漂移”和“抓取偏差”根源其实在感知链路没有闭环验证。3. 导航与运动规划动态行人场景下的安全通行3.1 全局规划与局部避障的分工商超机器人导航通常分为全局路径规划和局部避障两个层次。全局规划基于静态地图计算从当前位置到任务点的较优路径局部避障基于实时传感器数据在行走过程中避开行人和临时障碍物。层次输入输出更新频率典型实现全局路径规划静态地图、目标点离散路径点低频任务开始时或地图变化时Nav2 的 NavFn、Theta*局部轨迹规划实时代价地图、局部路径速度指令高频通常 10Hz 以上DWA、TEB、MPPI速度约束层传感器、安全区域速度限制指令高频急停和限速控制器在 ROS 2 的 Nav2 框架中这两层通过 costmap 和 planner/controller 配合实现。要理解一个原则全局规划负责“方向”局部规划负责“安全”。如果全局路径穿过一个错误标注的货架区域局部规划只能临时绕开但整体效率会变差如果局部代价地图更新太慢机器人会撞上突然出现的购物车。3.2 商超动态场景下的速度与安全参数商超导航不需要追求高速度而是追求“稳定可预期”。以下参数要按场景仔细调不能照抄仿真参数。参数含义影响robot_radius机器人外接圆半径过小会撞到货架过大会导致通道不可通行inflation_radius障碍物膨胀半径越大越安全但会让窄通道无法通行max_vel_x最大线速度商超推荐 0.5 m/s 以下行人区域建议 0.3 m/smax_vel_theta最大角速度过大会造成急转推车时容易侧翻acc_lim_x最大线加速度过大会导致急停过小会让机器人反应迟钝obstacle_timeout障碍物消失等待时间行人短暂停留时是否绕行取决于这个参数一个常见错误是直接使用默认参数运行。默认参数通常针对普通室内环境但商超通道宽度、货架间隙和行人密度都与办公室不同。如果地图中标注了不可通行区域全局 planner 会把路径绕到很远处如果膨胀半径过大原本能通行的通道会被判定为无解。下面是 Nav2 中局部代价地图和膨胀层的示意配置local_costmap: global_frame: map robot_base_frame: base_link update_frequency: 5.0 publish_frequency: 2.0 rolling_window: true width: 6.0 height: 6.0 resolution: 0.05 plugins: - { name: static_layer, type: nav2_costmap_2d::StaticLayer } - { name: inflation_layer, type: nav2_costmap_2d::InflationLayer } inflation_layer: inflation_radius: 0.4 cost_scaling_factor: 3.0这里的 inflation_radius 决定了地图障碍物向外膨胀的距离。如果机器人需要进入宽度较窄的货架补货可以单独设置“补货作业区域”的低膨胀半径但要用语义图层限制其他机器人进入避免碰撞。3.3 多机器人共用地图时的坐标与通信多台机器人同时运行时最容易出现的不是单机规划错误而是地图和定位坐标冲突。标准做法是所有机器人使用同一个 map 坐标系每台机器人拥有独立的 odom 和 base_link 变换调度中心只在 map 坐标系下统一管理位置。这样设计的原因是odom 坐标系会随每台机器人的里程计漂移不能直接用 odom 坐标做跨机器人避障map 坐标系由统一地图和 AMCL 定位给出所有任务点、充电桩、货架位置都基于 map 坐标。多机通信方面商超环境 WiFi 覆盖通常不均匀冷柜和金属货架会对信号产生干扰。机器人之间不适合高频广播大规模地图数据。建议把“全局地图、任务分配、状态上报”放到中心化调度服务机器人只订阅与自己相关的局部区域信息。这也能降低端侧算力和网络带宽压力。4. 机械臂抓取与商品操作从识别到位姿估计4.1 操作任务的分层结构具身智能机器人的机械臂操作可以拆成四层。第一层是目标识别确定“抓什么”。常见做法是使用目标检测模型识别商品类别并用分割模型或检测框得到商品在图像中的位置。第二层是位姿估计确定“在哪抓”。需要把 2D 图像中的商品位置映射到 3D 空间通常结合 RGB-D 点云计算目标物体的质心、表面法向量和可抓取区域。第三层是轨迹规划确定“怎么过去”。机械臂需要从当前姿态运动到预抓取姿态再沿接近方向到达抓取点。过程中要避开货架和相邻商品。第四层是执行与校验确定“抓没抓到”。机械臂夹爪闭合后需要用力传感器或视觉方法确认目标是否在夹爪内再决定继续搬运、调整姿态还是放弃。四个层之间是级联关系识别错误会导致位姿估计错误位姿估计错误会导致轨迹规划失败轨迹规划失败会表现为抓空或碰撞。因此排查抓取问题时要从最后一层向上倒退而不是一上来就调大模型。4.2 一个基于点云的抓取点估计示例下面给出一个最简化的抓取点估计示例。它说明的不是完整生产方案而是“如何从点云中得到一个可执行抓取姿态”的基本思路。实际项目需要结合商品类别、货架结构和夹爪型号调整。import numpy as np import open3d as o3d def estimate_grasp_pose_from_pointcloud(pcd_path): # 读取点云 pcd o3d.io.read_point_cloud(pcd_path) pcd.remove_non_finite_points() # 下采样减少计算量 down pcd.voxel_down_sample(0.01) # 使用 RANSAC 分割平面这里假设货架平面是最大平面 plane_model, inliers down.segment_plane( distance_threshold0.01, ransac_n3, num_iterations1000 ) remaining down.select_by_index(inliers, invertTrue) # 对剩余点做聚类找到目标物体 labels remaining.cluster_dbscan(eps0.02, min_points20) target_indices [ i for i, label in enumerate(labels) if label 0 ] if not target_indices: return None target_cloud remaining.select_by_index(target_indices) center target_cloud.get_center() normal np.asarray(center) - center # 占位正常应由主成分分析得到 return center实际项目中抓取点不会只取质心。夹爪接近方向需要根据货架和商品姿态确定常见的优先策略是“从上往下抓”或“从正前方抓”避免碰到相邻商品。姿态估计结果要经过运动学逆解检查确认机械臂能够到达并且整条路径不会发生碰撞。4.3 抓取失败检测与恢复抓取失败在真实场景中不可避免区别在于系统能否尽快发现并恢复。失败检测有两种常用方式基于力的方式夹爪闭合后如果接触力小于阈值说明没有抓稳如果接触力异常增大说明碰到货架或卡住。基于视觉的方式夹爪闭合后用相机确认目标商品是否离开货架位置或出现在夹爪区域。失败恢复策略要按照代价递增排序策略适用场景注意事项改变抓取点重试商品位置有偏差要限制重试次数避免机械臂反复撞击调整接近角度重试商品紧挨相邻物体需要先做碰撞检查放弃并上报物体状态异常记录失败图像和点云用于后续模型迭代请求人工介入无法自动恢复要设计安全的“人工接管”位姿避免机器人挡在通道中间实际运营中抓取成功率不是看单次概率而是看“最终完成率”。一次失败后有合理的重试和恢复策略整体完成率会远高于单次识别精度。因此抓取系统设计时要预留可观测接口记录每次抓取的目标图、点云、夹爪状态和结果用于离线分析。4.4 操作安全限速、力控与碰撞检测机械臂在商超环境中属于高风险部件。即使速度不高也可能夹到顾客手指或撞倒商品。所以操作安全不能只靠程序员的“小心”必须有硬件和软件双重保护。限速是第一步。机械臂末端速度要设定上限尤其在接近商品和货架时预抓取阶段可以高速运动接近阶段必须降速。力控是第二步。通过关节力矩传感器或末端六维力传感器检测接触力。一旦超过阈值机械臂应立即停止或反向退让。碰撞检测是第三步。即使没有力传感器也可以通过关节电流异常的突变进行简易碰撞检测但灵敏度会低很多。注意任何自动流程都要有一个物理急停按钮。无论调度系统、导航系统和机械臂系统写得多完善人工急停都是最后一道防线。商超环境更要在急停按钮旁做明显标识并纳入员工培训。5. 多机调度与任务编排规模化落地的系统底座5.1 从单机自主到多机协同单台机器人可以自主执行“从 A 点走到 B 点抓取商品放回 C 点”。但多台机器人同时运营时会出现几个新的问题同一台充电桩被多台机器人同时请求。两条机器人路径在窄通道相遇谁让谁。同一补货任务被两台机器人重复领取。一台机器人故障阻塞通道影响其他机器人通行。解决这些问题的核心是多机调度系统。它负责维护统一任务队列、监控机器人实时状态、分配互斥区域和决定任务优先级。机器人本身仍保留单机自主能力但“做什么、什么时候做、能不能进入某个区域”由调度系统统一控制。这种“中心调度 端侧自治”的架构比完全去中心化更容易落地。中心调度让任务分配和状态管理变得可控端侧自治则保证网络抖动时机器人不会立刻停摆。5.2 从订单到任务的拆解商超运营中的原始需求通常是“把 A 货架缺货的商品补上”“到 B 区域盘点”“把购物车带回集合区”。这些需求不能直接下发给机器人需要拆解成带前置条件和动作序列的任务。任务类型动作序列前置条件涉及能力货架补货移动到货架 - 识别缺货位 - 取货 - 放入货架商品在指定取货点导航、视觉识别、机械臂操作商品盘点沿路线移动 - 扫描条码 - 对比库存货架区域地图可用导航、视觉识别购物车归位移动到指定点 - 识别购物车 - 推送到回收区回收区空闲导航、路径规划、推车控制引导顾客移动到顾客位置 - 播放引导信息 - 跟随/领路顾客请求已确认导航、人机交互任务拆解的关键是明确“前置条件”。如果取货点没有商品补货任务一开始就注定失败。调度系统应该在任务下发前检查条件是否满足而不是把失败交给机器人现场处理。这能显著降低现场异常率。5.3 一个基于 Redis 的简单任务队列示例任务队列必须支持多台机器人同时领取任务且同一任务不能被重复领取。最简单可靠的方式是使用 Redis 的原子操作而不是先查询再更新。下面是一个简化示例用 Redis 的SET NX或 Lua 脚本实现任务领取的原子性import redis r redis.Redis(hostscheduler, port6379, db0) def claim_task(robot_id, task_id, timeout30): # 使用 SET NX EX 实现原子领取 result r.set(ftask:lock:{task_id}, robot_id, nxTrue, extimeout) if result: # 领取成功更新任务状态 r.hset(ftask:info:{task_id}, status, running) r.hset(ftask:info:{task_id}, robot, robot_id) return True return False这个示例说明的是“原子性”的重要性。如果先GET再SET两台机器人可能同时读到任务空闲状态然后同时领取。使用SET NX可以让 Redis 保证只有一个请求能写入成功从根上避免重复执行。任务完成后调度系统要负责释放锁、更新任务状态、记录执行结果任务超时后调度系统要重新分配任务而不是等机器人无限期执行下去。5.4 死锁与互斥区管理多机系统中最隐蔽的问题是死锁。典型场景两台机器人要在同一个窄通道相向而行如果双方都等待对方让路就会互相卡死。更复杂的死锁涉及多个区域机器人 A 占着充电桩机器人 B 需要充电但被 A 的路径挡住而 A 又想先完成另一个任务。常用解决方法有三种区域互斥把货架通道、充电桩、装卸区设为互斥资源同一时刻只允许一台机器人进入。方向规则在窄通道中规定默认方向或者按“任务优先级 距离出口”决定谁后退让路。全局死锁检测调度系统周期检查资源占用图和任务等待关系发现环状等待后主动干预。区域互斥实现相对简单但会降低通行效率。商超场景建议对真正危险的区域做互斥比如充电桩和装卸区普通通道靠导航规划器的避障逻辑处理不轻易做全域互斥。6. 数据闭环与远程运维规模化后真正的分水岭6.1 数据采集、清洗与标注具身智能系统的模型迭代依赖数据但“录一段视频”并不等于“采集到有效数据”。有效数据需要满足三个条件多源信息同步图像、点云、机器人位姿、任务状态、操作结果在同一时间基准下对齐。场景覆盖足够白天灯光、夜间灯光、雨天、周末人流高峰、促销堆头变化等不同条件都要覆盖。结果可反馈每一次抓取或导航异常都要有关联标签例如“抓取失败目标被遮挡”“导航失败通道堆满纸箱”。数据清洗阶段要过滤掉异常帧传感器时间戳错位、机器人急停、机械臂失控、点云全黑等数据不能进入训练集。标注阶段要根据任务决定标注粒度导航任务关注障碍物轮廓和可通行区域抓取任务关注商品检测框、3D 包围盒和抓取点。6.2 远程监控与异常恢复规模化运营后现场不可能每个区域都安排工程师盯着。远程监控系统要回答几个问题机器人当前在哪在做什么任务。任务队列里有多少任务哪些超时。各台机器人的在线率、任务完成率、抓取成功率是多少。机器人是否进入异常状态比如定位丢失、机械臂报错、轮子打滑。建议核心指标以表格形式维护指标含义正常参考区间异常应对在线率机器人连接调度系统的时长占比99% 以上检查网络和电源任务完成率完成任务数 / 下发任务数95% 以上分析失败原因归类抓取成功率单次抓取成功次数 / 总次数90% 以上检查模型、位姿、夹爪平均单任务耗时从领取到完成的时间根据任务定义排查路径绕行和排队人工介入率需要人工处理的次数越低越好优化自动恢复策略异常恢复要分级轻微异常由机器人自动重试中度异常让机器人回到安全位置再重试严重异常需要远程人工接管或现场人员介入。每一次人工介入都要记录原因和操作过程否则系统永远无法自动改进。6.3 开发环境与生产环境的部署差异很多团队在开发环境跑通后直接部署到商超结果出现各种奇怪问题。原因在于开发环境和生产环境的差异没有被正视。维度开发环境生产环境网络局域网稳定带宽充足WiFi 信号不稳定金属货架遮挡地图固定测试场地商超货架会调整任务要求跑通一条路径即可需要长时间无监督运行日志本地终端可见需要落盘、采集、远程检索软件升级直接重启或换代码需要灰度发布和回滚方案异常处理人工直接在机器人旁处理需要远程监控和现场配合生产环境部署前至少要补齐日志落盘、监控上报、OTA 回滚、权限管理四项能力。否则一旦有机器人卡死在货架中间或者软件升级引入致命 bug恢复时间会直接决定运营损失。7. 常见问题排查与最佳实践清单7.1 高频问题排查表以下是商超场景中常见的问题现象、可能原因和排查路径。适合打印出来作为现场排错清单。问题现象常见原因检查方式处理建议定位漂移机器人显示位置与实际不符地图过期、动态障碍物干扰定位、传感器标定变化在 RViz 中对比激光点云与地图是否对齐更新静态地图校准传感器查看 AMCL 粒子分布导航路径异常绕路代价地图膨胀半径过大、全局地图中有残留障碍查看全局规划路径和代价地图图层调整膨胀半径清理地图中过期障碍抓取失败率高位姿估计不准、目标被遮挡、夹爪不适合商品回放失败时的点云和图像增加训练数据调整抓取点策略更换夹爪同一任务被多台机器人重复执行任务领取不是原子操作查看任务状态和机器人日志使用 RedisSET NX或数据库唯一约束机器人卡在通道中不动局部规划找不到路径、等待超时未触发查看局部代价地图和速度指令增加等待超时恢复逻辑设置“原地旋转找路”策略远程监控看不到状态网络抖动、消息队列堆积、日志采集节点异常检查 WiFi 信号和消息队列积压增加本地缓存和断网续传机制7.2 落地上线前的检查清单上线前要逐项确认不要因为 DEMO 跑通就跳过地图是否基于最新货架布局生成并经过人工确认。传感器是否完成标定标定文件是否统一管理。导航参数是否在真实通道宽度下验证过。机械臂抓取是否覆盖了主要商品类别失败率是否可接受。多机调度是否做了区域互斥和死锁检测。任务超时是否有自动重试和重新分配机制。网络断连时机器人是否能安全停车或转入本地模式。是否有远程日志、监控指标和告警通道。物理急停按钮是否可用现场员工是否知道如何操作。软件升级是否有灰度发布和回滚方案。7.3 学习路线与工程落地建议如果团队要从零进入具身智能机器人商超落地方向建议学习路线按这个顺序推进。第一步先跑通 ROS 2 和仿真平台在一台虚拟机器人上完成建图、定位、导航的基础闭环。这样能避开真实硬件调试的干扰先把框架和概念建立起来。第二步把仿真中的导航和规划代码移植到真实底盘重点解决传感器标定、里程计精度和动态避障问题。第三步加入机械臂和视觉抓取先抓静态摆好的商品再逐步增加遮挡、不同商品种类和光照变化。第四步引入多机任务队列、区域互斥和远程监控让两台以上机器人同时运营。如果想在资源受限设备上做学习实验需要注意算力和内存限制。树莓派级别的设备更适合做导航小车验证不建议在低算力设备上同时跑大模型识别和稠密建图。建议把感知模型部署到独立算力盒子底盘只负责运动控制和轻量避障。仿真平台选择要考虑是否支持 RGB-D 相机和机械臂否则很难模拟完整的抓取流程。工程落地方面最重要的一条建议是先缩小场景复杂度再谈模型能力。与其让机器人在整层商超自由漫游不如先限定补货和目标区域与其追求一次抓取所有商品不如先聚焦几种长相规则、包装不反光的商品。稳定运营带来的数据和信任比一次性演示带来的技术震撼更有价值。只有把单点识别、路径规划、机械臂抓取、多机调度和远程运维串成一个可以持续运行的闭环具身智能机器人才算真正在商超场景立足。对团队来说接下来的重点不是不断增加新功能而是把失败模式收集全、把恢复逻辑写清楚、把每一项指标都变成可优化的数据。规模化的背后不是一次惊险的技术跳跃而是无数个边缘场景被逐一解决后的自然结果。