你是不是也有过这种时刻大疆的飞机在空中悬停、绕障、返航各种感知能力都稳稳当当但真把它放进家里的客厅、走廊或者桌底问题立刻变了一副面孔。空中那套“看得清、躲得开”的思路落到地面之后简直像换了一个物种。“地面交给大疆 ROMO2”——初看像是一个产品型号其实更像一个命题把无人机身上已经打磨成熟的感知技术从天空平移到一个更贴近日常的场景里变成居家省心的地面伙伴。ROMO2 在我们这篇文章里不指代某一款确切发布过的商业产品而是一个方向代号地面伙伴机器人在居家场景中如何承接、重构、落地无人机感知能力。真正值得讨论的不是传感器有多贵也不是算法有多前沿而是一整套空中感知逻辑换到地面坐标系之后为什么没有那么简单。这篇文章我想把这套逻辑拆开讲清楚。看完你会理解为什么“空中做得好”不代表“地面做得好”也会知道一个感知系统从天上落到地面要在定位、建图、避障、路径规划、工程回环、平台整合上经历哪些坎。这不是一篇产品评测是一篇技术判断和落地路线梳理。1. 先搞明白空中感知能力的成熟不等于地面场景照搬就能用大疆最擅长的事情是把“稳定飞行”变成一种默认能力。GNSS 定位、视觉里程计、多向避障、智能返航这些模块在空中已经打磨得很成熟。你会默认飞机知道自己在哪儿默认它能绕开树枝和电线默认它在丢星之后还能靠视觉顶一阵。这些“默认”就是感知技术在理想环境里高度产品化的结果。1.1 空中是一个“结构化稀疏环境”地面是一个“非结构化密堆环境”空中场景的最大特点是空旷。障碍物稀疏目标物距离远光照相对均匀GPS 信号大多时候可用。感知系统在处理空中问题时主要任务是在广阔视野中识别少量关键障碍物然后规划一条足够宽的安全走廊。地面场景完全不同。居家环境下障碍物密度极高家具、墙面、桌椅、线缆、宠物、拖鞋全都挤在几平方米范围内。感知系统的任务不再是“发现远处的一个杆子”而是“在密集、交错、随时变化的物体堆里找到一条可通行的窄缝”。这意味着两类东西要重做空间分辨率要求变了。空中识别一个几十厘米的树枝可能只需要知道“有障碍绕远一点”地面识别一个桌腿你需要知道它精确的位置、尺寸、能否从左侧 3 厘米处通过。动态物体模型变了。空中的动态目标主要是其他飞行器或鸟速度高、轨迹简单地面的动态目标是人、宠物、门、柜门速度快慢不一方向突变频繁还经常出现“刚才还在这里现在突然不在”的消失问题。1.2 参考系不同一个对世界定位一个对自身定位空中飞行的定位重点是回答“我在世界中的哪个位置”。飞手或者后台看到的是经纬度、高度、航向角。地面伙伴机器人更多时候要回答的不是“全局坐标”而是“房间里的局部位置、门框相对于我身体的朝向、目标物体到我抓取手的相对距离”。它的任务不是飞到某个经纬度上空而是“穿过卧室门走到茶几旁在距离沙发 40 厘米处停住”。所以你会发现很多从空中拿过来的定位算法第一关就卡在坐标系转换上。空中常用的 ECEF、经纬度、航向角体系到了室内必须切换为局部里程计、平面坐标和姿态四元数。这个切换看似只是个数学问题实际上是整个后端、路径规划、交互逻辑都要跟着变。这类问题在社区里一直存在。比如有开发者问“Fast-LIO 自带的坐标转换能否直接用于无人机”表面上是问一个算法接口实际上是在问“不同载体运动模型下的坐标系约定能不能共用一套外参标定逻辑”。答案通常是不能至少不能不做校验就硬套。2. 一个地面伙伴感知系统的四层骨架到底长什么样如果抛开品牌和具体型号任何“地面交给机器人”项目感知侧都逃不开四层骨架定位、建图、感知避障、路径规划。这四层单独看都不是新东西但组合在一起、还要跑在居家场景里每一层都在刷新空中方案默认的假设。2.1 第一层定位从“RTK 固定解”到“局部连续估计”空中定位最理想的状态是 RTK 固定解厘米级、全球统一、几乎无漂移。但室内没有这种条件更多时候要靠激光惯性里程计、视觉惯性里程计或者两者融合。这一层的难度不是“算法选型”而是“长期运行不漂移”。居家场景中机器人会反复经过同一条走廊如果里程计产生累积漂移地图和真实环境就会逐渐错位最终表现为“明明地图上显示门在左边车却往右边墙上撞”。工程上常用的补救思路是回环检测。但回环检测在室内有另一个坑家具经常被移动同一个位置在不同时刻的观感可能差别很大。你今天在这里放了一盆绿植明天移走了机器人如果执着于旧地图就会在原来放绿植的地方出现“虚拟障碍”。所以地面伙伴机器人的定位系统必须同时处理“稳定回环”和“地图动态更新”这对矛盾。2.2 第二层建图从“稀疏点云”到“语义可交互地图”空中建图很多时候要的是稀疏点云或者航测模型用来做测绘、重建或者巡检比对精度要求高但人对地图的交互需求低。居家场景正好反过来。机器人的地图不只是要“长得多像真实环境”更要回答一系列语义问题哪里是出入口哪里是桌子哪里是地毯不能碾过哪里是宠物饭碗需要绕行。纯几何地图给不出这些信息必须叠加语义层。这一层最容易犯的错误是以为只要装一个 RGB-D 相机或者跑一个 YOLO 模型就能完成语义建图。实际上语义建图要解决的是“把识别结果稳定地写进地图并且持续更新”。单帧识别准确率再高如果不知道如何融合到地图坐标里输出也只是一堆飘动的检测框。补充一句现在很多开源数据集和预训练模型做得已经很好了比如无人机低空航拍数据集、YOLO 系列检测框架但地面视角的数据集要少得多。你在空中数据上训练出的模型放到地面视角后性能下降往往不是模型问题而是域差异问题。2.3 第三层感知避障从“绕障”到“细粒度通行判断”空中避障以“绕”为主。遇到障碍升高或侧移绕过去就有大片空域可以使用。地面避障则经常要回答“要不要穿过去”“能不能从这 3 厘米挤过去”。我把这种能力叫做“细粒度通行判断”。它要求机器人同时处理静态障碍物的精确边界桌腿的半径、墙面的平面度、台阶的边缘。低矮物体的识别电线、拖鞋、宠物尾巴激光雷达的扫描平面可能根本扫不到。盲区补偿机器人底盘前方的近距离盲区往往才是最容易撞到东西的地方。从实际经验看很多地面项目在避障上的第一版都做得很粗糙基本逻辑是“检测到障碍就停”这确实安全但没什么用。一个居家省心伙伴如果走三步停两步它给你带来的不是省心是挫败感。真正的避障策略必须是分级的可以远距离减速、可以近距离绕行、只有少数情况才需要急停。2.4 第四层路径规划从“点到点航线”到“任务态规划”空中路径规划和地面路径规划的最大差异不在算法的复杂程度而在规划目标。空中路径规划通常是点到点定义一个起点、一个终点、几个途经点算法负责生成一条安全航线。地面路径规划则是任务态规划它必须理解当前的“任务意图”我是要去充电座去茶几送东西还是去门口迎接主人不同意图下路径选择逻辑完全不同。去充电座可能需要精确停靠、调整朝向去送东西需要在目标附近预留交互空间去迎接主人路径规划要表现得自然、不突兀、不挡路。还有一层容易被忽略路径规划不是一次性算完就结束的。居家环境随时变化规划系统必须持续监控地图变化、障碍物变化、自身定位偏移然后动态调整路径。这也是为什么很多无人机上能用的全局规划算法原封不动搬到地面上后表现极差——它们的重规划频率和动态感知频率根本不匹配。3. 从“天上”到“地面”真正难的往往不是算法是工程很多团队做地面感知项目前两周最兴奋算法 demo 跑得很顺第三周开始进入崩溃期问题集中在坐标系标定、数据同步、设备时延、日志缺失和各类环境差异上。这不是团队不行而是因为地面场景把工程问题放大了。3.1 第一道坎坐标转换不是数学题是标定题你用的雷达、相机、IMU、底盘轮式里程计各有各的坐标系。理论上只要有外参标定结果就能把不同传感器数据统一到一个坐标系里。但“理论上”和“实际能用”之间隔着好几层问题外参在长时间运行后会漂移尤其在底盘震动大的场景里。标定板、标定环境和实际使用环境差异过大会导致模型在真实场景中不自洽。不同传感器时间同步没做好坐标系校准得再对融合结果也是错的。关于“Fast-LIO 自带的坐标转换能不能直接用于无人机”其实也是一个标定链路完整性的问题。Fast-LIO 的坐标转换约定是给自己的算法框架用的拿到另一套载体上必须重新确认 IMU 与雷达的外参、IMU 与车体/机体的外参、时延补偿参数否则融合结果大概率发散。我见过太多项目排错排到最后发现不是算法问题而是某个外参文件用的是旧版本标定结果。所以工程上第一件事不是调算法而是把每台设备的“传感器到车体”外参、时间同步方式、日志格式全部定死。3.2 第二道坎数据集和仿真环境永远“不够像”很多项目在仿真环境里跑得很好一到真机就露馅。原因很简单仿真环境里的传感器噪声、物体纹理、光照变化、物理交互都被不同程度地“美化”了。地面感知尤其是居家场景对以下变量的容忍度非常低光照变化白天、夜晚、窗帘半拉、灯光色温不同视觉退化程度完全不同。反射与透明材质茶几玻璃、落地窗、光面地砖会同时骗过激光雷达和深度相机。低纹理区域白墙、白地板、纯色柜门对视觉里程计非常不友好。我建议的路线是先真机采集一批真实数据再把这些数据灌回仿真里做增强而不是直接依赖仿真环境生成训练数据。也就是说仿真不是用来替代真机的是用来放大真实数据的。3.3 第三道坎Offboard 模式只是开始任务闭环才是重点无人机开发者比较熟悉 Offboard 模式也就是把飞控的决策权交给外部计算单元外部负责感知、规划、决策底层只负责姿态控制。地面机器人在工程架构上类似。底层运动控制由轮式底盘或飞控负责上层感知和规划跑在独立算力平台上。很多团队以为打通了通信链路能把速度指令发给底盘项目就完成了一大半。但说句实在话通信打通只是刚开始后面还有一长串问题等着你如何保证感知节点挂掉时底盘能进入安全停车状态如何让规划节点和底盘控制节点使用同一条时间基准如何记录每个时刻的感知输入、规划输出、运动反馈以便事后复盘这些都不会写在任何开源项目的 README 里但每一个都能让项目从“demo 可跑”变成“真的能用”。3.4 项目掉链子时的排查链路如果感知系统在地面场景中表现异常别着急改参数更不要马上换模型。按下面的顺序排查先看现象是定位漂移、避障漏检、路径中断、还是偶发抖动现象不明确后面都白做。再看数据输入传感器时间戳是否对齐、图像是否丢帧、点云是否时间跳跃、编码是否正常。再看标定和环境外参是否有效、相机和雷达覆盖是否匹配实际视角、灯光是否变化、地面材质是否不同。再看算力资源CPU/GPU 占用是否打满、内存是否抖动、日志 IO 是否阻塞、通信是否有断连。再看参数配置地图分辨率、障碍物膨胀半径、规划频率、最大速度和加速度限制是否合理。最后才看算法模块本身定位模块、检测模块、规划模块哪个模块的输出最不符合预期再做模块级定位。这个顺序的核心逻辑是“先排除环境、设备和数据层问题再动算法”。大多数地面感知项目的问题都出在前三步而不是算法本身。4. 把一次跑通变成可复用工程我从实践中总结的三步框架如果一个地面感知项目只跑一次 demo很多坑是可以凑合绕过去的。但要做成一个“居家省心伙伴”必须把它从“单次跑通”推进到“可复用工程”。这里有一个我实践后觉得比较顺的三步框架。4.1 第一步最小闭环先把“传感器到运动”的链路完整盘活第一步不要追求多传感器全上先用最小配置跑通完整闭环。以 ROMO2 这类地面伙伴场景为例最小配置可以是一台深度相机或一个单线激光雷达、一个 IMU、一块能跑轻量模型的算力板、一个带速度控制的底盘。目标只有一个让机器人在一个限定区域内从位置 A 自主走到位置 B并且能避开一个静态障碍物。这一步不是为了验证算法先进性而是为了验证整条链路有没有“断点”。链路里最容易断的地方不是感知而是时间对齐和通信延迟。视觉里程计输出的是带时间戳的位姿底盘控制需要的是实时速度指令两者哪怕只差 100 毫秒表现起来就是路径抖动。所以第一步就要把日志系统建好每个模块的输入输出都记录带时间戳后续排查会省很多时间。4.2 第二步数据留痕和异常重试决定系统能不能长期跑最小闭环跑通之后普通项目可能就急着加功能了。但我的建议是先补两个看起来不性感、但长期价值极高的模块数据留痕把每次运行的传感器数据、算法中间结果、控制指令、系统状态全部落盘。异常重试定义好哪些情况需要重试、哪些情况需要慢速重跑、哪些情况必须停下来等人处理。先别急着做复杂交互。先让系统在无人干预的情况下能连续跑 10 次每次都能自主完成“走到目标点”的任务。过程中任何一次卡死、抖动、漂移都要有日志可以追溯。很多团队抱怨机器人“偶尔抽风”但拿不出日志也没法复现。这种项目说白了还没到调算法的阶段先解决可观测性问题才是当前最紧急的问题。4.3 第三步平台化集成把单机智能变成可管理的能力当单机跑稳之后才轮到平台化。这一步涉及控制台、地图管理、任务下发、状态监控、多机协同这些更高层的话题。在无人机行业里这类能力通常对应“管控平台”比如司空这类平台可以管理多个飞行器、下发航线、查看状态、回传数据。在地面伙伴机器人里其实也需要类似的一套东西设备管理每台机器人在线、离线、正在执行什么任务。地图和区域管理不同楼层、不同房间的地图如何存储和更新。任务编排什么时间、去哪个位置、执行什么操作、失败后怎么处理。远程介入机器人解决不了时如何让人快速接管。看到这里你可能明白了为什么很多团队在做“无人机管控平台”“大疆司空私有化部署”“无人机管理平台开发”这类词时会特别关注私有化部署和源码级二次开发。因为感知能力只是最底下的一层真正要被反复使用和维护的是上层那套平台能力。5. 做“居家省心伙伴”不能只卷感知还要补任务、交互和安全感知只是机器人的眼睛和耳朵真正让用户觉得“省心”的是整个任务链路理解需求、规划行动、执行操作、确认反馈、异常求助。5.1 任务定义比“能走”更重要的是“知道该做什么”对居家场景来说感知系统的难点远不止“看清环境”真正复杂的是“把模糊需求转化为具体任务”。比如“看看厨房地上有没有水”这是一个非常自然的需求。但机器人要拆成多个子任务从当前房间规划到厨房、在行进过程中避开桌椅、到达厨房后切换扫描模式、识别地面水渍区域、判断是否值得报告。这一串操作背后感知只是其中一环更重要的是任务分解和状态管理。如果只做一个“能平稳行走”的机器人其实离“省心伙伴”还很远。要让用户觉得省心必须让机器人具备任务抽象能力把用户的模糊指令变成可执行、可验证、可反馈的任务。5.2 交互方式从遥控器到自然指令体验会跨一个台阶无人机时代的交互是遥控器和航线预设地面伙伴机器人面对的交互对象主要是非专业用户。用户不会想学 MAVLink 协议不会想配置地面站他们只想要自然的结果“把药放到床头”“去客厅拍张照片”“门口好像有人去看一眼”。更好的交互方案是把大模型语言能力、语音识别、视觉理解串成一条流水线。用户说话系统解析任务机器人感知环境并执行。看起来像“AI 聊天机器人加了个身体”但工程复杂度高了很多。因为自然语言解析出的任务往往是不完整的比如“看一下门口”机器人需要自己去补齐“看”的具体方式、位置和判断标准。5.3 安全边界低速、低算力、低置信度时的兜底策略居家场景的安全边界和空中完全不一样。空中坠机可能导致财产损失或人身伤害地面机器人的最高速度一般较低但它的日常场景里全是人尤其是老人、小孩和宠物。所以设计上要额外考虑速度上限要保守不能为了“聪明感”牺牲安全。接近人时要有明确的减速和等待策略。低置信度状态下应该主动停下来而不是硬着头皮继续执行。必须有物理急停开关方便人在紧急情况下直接打断。我见过不少项目在 demo 时把速度调得飞快视觉上确实更“灵活”但一旦进入真实家庭这种设置会很快变成事故隐患。安全策略不是锦上添花是地面机器人的默认设计前提。6. 哪些项目适合做哪些场景不适合以及我给你的建议把“地面交给大疆 ROMO2”这几层逻辑聊完之后还有一件重要的事这套方案不是万能药它有自己的适用边界。6.1 适合什么如果你满足以下条件这一类“地面伙伴感知系统”就很有参考价值你的项目需要让机器人/智能车在室内或半结构化园区环境中稳定行走例如物资配送、巡检、陪伴、安防。你已经有比较成熟的底层运动控制缺的是上层感知和任务规划能力。你在测量、数据采集、场景理解上有明确需求而不是只想做一个技术 demo。你愿意在日志、标定、数据留痕、异常处理这些工程环节上投入时间而不是只盯着模型精度。6.2 不适合什么反过来下面这些情况建议谨慎你需要在完全无 GPS 的开阔地面上做长距离、高精度定位。地面感知方案的里程计适合局部场景全局长距离还是需要额外的路标或高精度地图配合。你的场景物体变动极其频繁而且没有规律。比如天天换布局的仓库、堆满杂物的临时场地感知系统会很难维持稳定的地图和避障策略。你想不经过最小闭环直接上一堆传感器和模型。地面感知系统最怕“多而不稳”感知层越多标定和同步问题越严重。你没有日志系统全靠肉眼看现象猜问题。没有可观测性任何排查都会变成玄学。6.3 下一步最该做什么如果让我给一句话建议别急着上多传感器阵列也先别追求技术演示的“炸场”。找一个 20 平米的室内空间把最小闭环跑稳连续运行 10 次不出问题再用日志复盘每一次的细节差异你会发现整个系统的真实瓶颈在哪里。之后再去扩展语义识别、语音交互、平台管理、多机协同每一步都有清晰的基础支撑。这个顺序比追着热搜词走要稳妥得多。回到最开始那个命题空中感知技术的成熟给地面场景提供了一堆高质量的“零件”但零件不等于整车。真正的工程价值在于把这些零件重新适配到一个新的物理世界和工作流里。ROMO2 这类地面伙伴本质上是空中技术思维方式的一次换乘——从导航坐标系进入生活坐标系。谁先把这件事做顺谁才能真正让用户感到省心。 
长河君 · 2026/8/31 22:05:05 · 阅读 1.2k 从空中到地面：地面伙伴机器人感知系统落地路线分析
你是不是也有过这种时刻大疆的飞机在空中悬停、绕障、返航各种感知能力都稳稳当当但真把它放进家里的客厅、走廊或者桌底问题立刻变了一副面孔。空中那套“看得清、躲得开”的思路落到地面之后简直像换了一个物种。“地面交给大疆 ROMO2”——初看像是一个产品型号其实更像一个命题把无人机身上已经打磨成熟的感知技术从天空平移到一个更贴近日常的场景里变成居家省心的地面伙伴。ROMO2 在我们这篇文章里不指代某一款确切发布过的商业产品而是一个方向代号地面伙伴机器人在居家场景中如何承接、重构、落地无人机感知能力。真正值得讨论的不是传感器有多贵也不是算法有多前沿而是一整套空中感知逻辑换到地面坐标系之后为什么没有那么简单。这篇文章我想把这套逻辑拆开讲清楚。看完你会理解为什么“空中做得好”不代表“地面做得好”也会知道一个感知系统从天上落到地面要在定位、建图、避障、路径规划、工程回环、平台整合上经历哪些坎。这不是一篇产品评测是一篇技术判断和落地路线梳理。1. 先搞明白空中感知能力的成熟不等于地面场景照搬就能用大疆最擅长的事情是把“稳定飞行”变成一种默认能力。GNSS 定位、视觉里程计、多向避障、智能返航这些模块在空中已经打磨得很成熟。你会默认飞机知道自己在哪儿默认它能绕开树枝和电线默认它在丢星之后还能靠视觉顶一阵。这些“默认”就是感知技术在理想环境里高度产品化的结果。1.1 空中是一个“结构化稀疏环境”地面是一个“非结构化密堆环境”空中场景的最大特点是空旷。障碍物稀疏目标物距离远光照相对均匀GPS 信号大多时候可用。感知系统在处理空中问题时主要任务是在广阔视野中识别少量关键障碍物然后规划一条足够宽的安全走廊。地面场景完全不同。居家环境下障碍物密度极高家具、墙面、桌椅、线缆、宠物、拖鞋全都挤在几平方米范围内。感知系统的任务不再是“发现远处的一个杆子”而是“在密集、交错、随时变化的物体堆里找到一条可通行的窄缝”。这意味着两类东西要重做空间分辨率要求变了。空中识别一个几十厘米的树枝可能只需要知道“有障碍绕远一点”地面识别一个桌腿你需要知道它精确的位置、尺寸、能否从左侧 3 厘米处通过。动态物体模型变了。空中的动态目标主要是其他飞行器或鸟速度高、轨迹简单地面的动态目标是人、宠物、门、柜门速度快慢不一方向突变频繁还经常出现“刚才还在这里现在突然不在”的消失问题。1.2 参考系不同一个对世界定位一个对自身定位空中飞行的定位重点是回答“我在世界中的哪个位置”。飞手或者后台看到的是经纬度、高度、航向角。地面伙伴机器人更多时候要回答的不是“全局坐标”而是“房间里的局部位置、门框相对于我身体的朝向、目标物体到我抓取手的相对距离”。它的任务不是飞到某个经纬度上空而是“穿过卧室门走到茶几旁在距离沙发 40 厘米处停住”。所以你会发现很多从空中拿过来的定位算法第一关就卡在坐标系转换上。空中常用的 ECEF、经纬度、航向角体系到了室内必须切换为局部里程计、平面坐标和姿态四元数。这个切换看似只是个数学问题实际上是整个后端、路径规划、交互逻辑都要跟着变。这类问题在社区里一直存在。比如有开发者问“Fast-LIO 自带的坐标转换能否直接用于无人机”表面上是问一个算法接口实际上是在问“不同载体运动模型下的坐标系约定能不能共用一套外参标定逻辑”。答案通常是不能至少不能不做校验就硬套。2. 一个地面伙伴感知系统的四层骨架到底长什么样如果抛开品牌和具体型号任何“地面交给机器人”项目感知侧都逃不开四层骨架定位、建图、感知避障、路径规划。这四层单独看都不是新东西但组合在一起、还要跑在居家场景里每一层都在刷新空中方案默认的假设。2.1 第一层定位从“RTK 固定解”到“局部连续估计”空中定位最理想的状态是 RTK 固定解厘米级、全球统一、几乎无漂移。但室内没有这种条件更多时候要靠激光惯性里程计、视觉惯性里程计或者两者融合。这一层的难度不是“算法选型”而是“长期运行不漂移”。居家场景中机器人会反复经过同一条走廊如果里程计产生累积漂移地图和真实环境就会逐渐错位最终表现为“明明地图上显示门在左边车却往右边墙上撞”。工程上常用的补救思路是回环检测。但回环检测在室内有另一个坑家具经常被移动同一个位置在不同时刻的观感可能差别很大。你今天在这里放了一盆绿植明天移走了机器人如果执着于旧地图就会在原来放绿植的地方出现“虚拟障碍”。所以地面伙伴机器人的定位系统必须同时处理“稳定回环”和“地图动态更新”这对矛盾。2.2 第二层建图从“稀疏点云”到“语义可交互地图”空中建图很多时候要的是稀疏点云或者航测模型用来做测绘、重建或者巡检比对精度要求高但人对地图的交互需求低。居家场景正好反过来。机器人的地图不只是要“长得多像真实环境”更要回答一系列语义问题哪里是出入口哪里是桌子哪里是地毯不能碾过哪里是宠物饭碗需要绕行。纯几何地图给不出这些信息必须叠加语义层。这一层最容易犯的错误是以为只要装一个 RGB-D 相机或者跑一个 YOLO 模型就能完成语义建图。实际上语义建图要解决的是“把识别结果稳定地写进地图并且持续更新”。单帧识别准确率再高如果不知道如何融合到地图坐标里输出也只是一堆飘动的检测框。补充一句现在很多开源数据集和预训练模型做得已经很好了比如无人机低空航拍数据集、YOLO 系列检测框架但地面视角的数据集要少得多。你在空中数据上训练出的模型放到地面视角后性能下降往往不是模型问题而是域差异问题。2.3 第三层感知避障从“绕障”到“细粒度通行判断”空中避障以“绕”为主。遇到障碍升高或侧移绕过去就有大片空域可以使用。地面避障则经常要回答“要不要穿过去”“能不能从这 3 厘米挤过去”。我把这种能力叫做“细粒度通行判断”。它要求机器人同时处理静态障碍物的精确边界桌腿的半径、墙面的平面度、台阶的边缘。低矮物体的识别电线、拖鞋、宠物尾巴激光雷达的扫描平面可能根本扫不到。盲区补偿机器人底盘前方的近距离盲区往往才是最容易撞到东西的地方。从实际经验看很多地面项目在避障上的第一版都做得很粗糙基本逻辑是“检测到障碍就停”这确实安全但没什么用。一个居家省心伙伴如果走三步停两步它给你带来的不是省心是挫败感。真正的避障策略必须是分级的可以远距离减速、可以近距离绕行、只有少数情况才需要急停。2.4 第四层路径规划从“点到点航线”到“任务态规划”空中路径规划和地面路径规划的最大差异不在算法的复杂程度而在规划目标。空中路径规划通常是点到点定义一个起点、一个终点、几个途经点算法负责生成一条安全航线。地面路径规划则是任务态规划它必须理解当前的“任务意图”我是要去充电座去茶几送东西还是去门口迎接主人不同意图下路径选择逻辑完全不同。去充电座可能需要精确停靠、调整朝向去送东西需要在目标附近预留交互空间去迎接主人路径规划要表现得自然、不突兀、不挡路。还有一层容易被忽略路径规划不是一次性算完就结束的。居家环境随时变化规划系统必须持续监控地图变化、障碍物变化、自身定位偏移然后动态调整路径。这也是为什么很多无人机上能用的全局规划算法原封不动搬到地面上后表现极差——它们的重规划频率和动态感知频率根本不匹配。3. 从“天上”到“地面”真正难的往往不是算法是工程很多团队做地面感知项目前两周最兴奋算法 demo 跑得很顺第三周开始进入崩溃期问题集中在坐标系标定、数据同步、设备时延、日志缺失和各类环境差异上。这不是团队不行而是因为地面场景把工程问题放大了。3.1 第一道坎坐标转换不是数学题是标定题你用的雷达、相机、IMU、底盘轮式里程计各有各的坐标系。理论上只要有外参标定结果就能把不同传感器数据统一到一个坐标系里。但“理论上”和“实际能用”之间隔着好几层问题外参在长时间运行后会漂移尤其在底盘震动大的场景里。标定板、标定环境和实际使用环境差异过大会导致模型在真实场景中不自洽。不同传感器时间同步没做好坐标系校准得再对融合结果也是错的。关于“Fast-LIO 自带的坐标转换能不能直接用于无人机”其实也是一个标定链路完整性的问题。Fast-LIO 的坐标转换约定是给自己的算法框架用的拿到另一套载体上必须重新确认 IMU 与雷达的外参、IMU 与车体/机体的外参、时延补偿参数否则融合结果大概率发散。我见过太多项目排错排到最后发现不是算法问题而是某个外参文件用的是旧版本标定结果。所以工程上第一件事不是调算法而是把每台设备的“传感器到车体”外参、时间同步方式、日志格式全部定死。3.2 第二道坎数据集和仿真环境永远“不够像”很多项目在仿真环境里跑得很好一到真机就露馅。原因很简单仿真环境里的传感器噪声、物体纹理、光照变化、物理交互都被不同程度地“美化”了。地面感知尤其是居家场景对以下变量的容忍度非常低光照变化白天、夜晚、窗帘半拉、灯光色温不同视觉退化程度完全不同。反射与透明材质茶几玻璃、落地窗、光面地砖会同时骗过激光雷达和深度相机。低纹理区域白墙、白地板、纯色柜门对视觉里程计非常不友好。我建议的路线是先真机采集一批真实数据再把这些数据灌回仿真里做增强而不是直接依赖仿真环境生成训练数据。也就是说仿真不是用来替代真机的是用来放大真实数据的。3.3 第三道坎Offboard 模式只是开始任务闭环才是重点无人机开发者比较熟悉 Offboard 模式也就是把飞控的决策权交给外部计算单元外部负责感知、规划、决策底层只负责姿态控制。地面机器人在工程架构上类似。底层运动控制由轮式底盘或飞控负责上层感知和规划跑在独立算力平台上。很多团队以为打通了通信链路能把速度指令发给底盘项目就完成了一大半。但说句实在话通信打通只是刚开始后面还有一长串问题等着你如何保证感知节点挂掉时底盘能进入安全停车状态如何让规划节点和底盘控制节点使用同一条时间基准如何记录每个时刻的感知输入、规划输出、运动反馈以便事后复盘这些都不会写在任何开源项目的 README 里但每一个都能让项目从“demo 可跑”变成“真的能用”。3.4 项目掉链子时的排查链路如果感知系统在地面场景中表现异常别着急改参数更不要马上换模型。按下面的顺序排查先看现象是定位漂移、避障漏检、路径中断、还是偶发抖动现象不明确后面都白做。再看数据输入传感器时间戳是否对齐、图像是否丢帧、点云是否时间跳跃、编码是否正常。再看标定和环境外参是否有效、相机和雷达覆盖是否匹配实际视角、灯光是否变化、地面材质是否不同。再看算力资源CPU/GPU 占用是否打满、内存是否抖动、日志 IO 是否阻塞、通信是否有断连。再看参数配置地图分辨率、障碍物膨胀半径、规划频率、最大速度和加速度限制是否合理。最后才看算法模块本身定位模块、检测模块、规划模块哪个模块的输出最不符合预期再做模块级定位。这个顺序的核心逻辑是“先排除环境、设备和数据层问题再动算法”。大多数地面感知项目的问题都出在前三步而不是算法本身。4. 把一次跑通变成可复用工程我从实践中总结的三步框架如果一个地面感知项目只跑一次 demo很多坑是可以凑合绕过去的。但要做成一个“居家省心伙伴”必须把它从“单次跑通”推进到“可复用工程”。这里有一个我实践后觉得比较顺的三步框架。4.1 第一步最小闭环先把“传感器到运动”的链路完整盘活第一步不要追求多传感器全上先用最小配置跑通完整闭环。以 ROMO2 这类地面伙伴场景为例最小配置可以是一台深度相机或一个单线激光雷达、一个 IMU、一块能跑轻量模型的算力板、一个带速度控制的底盘。目标只有一个让机器人在一个限定区域内从位置 A 自主走到位置 B并且能避开一个静态障碍物。这一步不是为了验证算法先进性而是为了验证整条链路有没有“断点”。链路里最容易断的地方不是感知而是时间对齐和通信延迟。视觉里程计输出的是带时间戳的位姿底盘控制需要的是实时速度指令两者哪怕只差 100 毫秒表现起来就是路径抖动。所以第一步就要把日志系统建好每个模块的输入输出都记录带时间戳后续排查会省很多时间。4.2 第二步数据留痕和异常重试决定系统能不能长期跑最小闭环跑通之后普通项目可能就急着加功能了。但我的建议是先补两个看起来不性感、但长期价值极高的模块数据留痕把每次运行的传感器数据、算法中间结果、控制指令、系统状态全部落盘。异常重试定义好哪些情况需要重试、哪些情况需要慢速重跑、哪些情况必须停下来等人处理。先别急着做复杂交互。先让系统在无人干预的情况下能连续跑 10 次每次都能自主完成“走到目标点”的任务。过程中任何一次卡死、抖动、漂移都要有日志可以追溯。很多团队抱怨机器人“偶尔抽风”但拿不出日志也没法复现。这种项目说白了还没到调算法的阶段先解决可观测性问题才是当前最紧急的问题。4.3 第三步平台化集成把单机智能变成可管理的能力当单机跑稳之后才轮到平台化。这一步涉及控制台、地图管理、任务下发、状态监控、多机协同这些更高层的话题。在无人机行业里这类能力通常对应“管控平台”比如司空这类平台可以管理多个飞行器、下发航线、查看状态、回传数据。在地面伙伴机器人里其实也需要类似的一套东西设备管理每台机器人在线、离线、正在执行什么任务。地图和区域管理不同楼层、不同房间的地图如何存储和更新。任务编排什么时间、去哪个位置、执行什么操作、失败后怎么处理。远程介入机器人解决不了时如何让人快速接管。看到这里你可能明白了为什么很多团队在做“无人机管控平台”“大疆司空私有化部署”“无人机管理平台开发”这类词时会特别关注私有化部署和源码级二次开发。因为感知能力只是最底下的一层真正要被反复使用和维护的是上层那套平台能力。5. 做“居家省心伙伴”不能只卷感知还要补任务、交互和安全感知只是机器人的眼睛和耳朵真正让用户觉得“省心”的是整个任务链路理解需求、规划行动、执行操作、确认反馈、异常求助。5.1 任务定义比“能走”更重要的是“知道该做什么”对居家场景来说感知系统的难点远不止“看清环境”真正复杂的是“把模糊需求转化为具体任务”。比如“看看厨房地上有没有水”这是一个非常自然的需求。但机器人要拆成多个子任务从当前房间规划到厨房、在行进过程中避开桌椅、到达厨房后切换扫描模式、识别地面水渍区域、判断是否值得报告。这一串操作背后感知只是其中一环更重要的是任务分解和状态管理。如果只做一个“能平稳行走”的机器人其实离“省心伙伴”还很远。要让用户觉得省心必须让机器人具备任务抽象能力把用户的模糊指令变成可执行、可验证、可反馈的任务。5.2 交互方式从遥控器到自然指令体验会跨一个台阶无人机时代的交互是遥控器和航线预设地面伙伴机器人面对的交互对象主要是非专业用户。用户不会想学 MAVLink 协议不会想配置地面站他们只想要自然的结果“把药放到床头”“去客厅拍张照片”“门口好像有人去看一眼”。更好的交互方案是把大模型语言能力、语音识别、视觉理解串成一条流水线。用户说话系统解析任务机器人感知环境并执行。看起来像“AI 聊天机器人加了个身体”但工程复杂度高了很多。因为自然语言解析出的任务往往是不完整的比如“看一下门口”机器人需要自己去补齐“看”的具体方式、位置和判断标准。5.3 安全边界低速、低算力、低置信度时的兜底策略居家场景的安全边界和空中完全不一样。空中坠机可能导致财产损失或人身伤害地面机器人的最高速度一般较低但它的日常场景里全是人尤其是老人、小孩和宠物。所以设计上要额外考虑速度上限要保守不能为了“聪明感”牺牲安全。接近人时要有明确的减速和等待策略。低置信度状态下应该主动停下来而不是硬着头皮继续执行。必须有物理急停开关方便人在紧急情况下直接打断。我见过不少项目在 demo 时把速度调得飞快视觉上确实更“灵活”但一旦进入真实家庭这种设置会很快变成事故隐患。安全策略不是锦上添花是地面机器人的默认设计前提。6. 哪些项目适合做哪些场景不适合以及我给你的建议把“地面交给大疆 ROMO2”这几层逻辑聊完之后还有一件重要的事这套方案不是万能药它有自己的适用边界。6.1 适合什么如果你满足以下条件这一类“地面伙伴感知系统”就很有参考价值你的项目需要让机器人/智能车在室内或半结构化园区环境中稳定行走例如物资配送、巡检、陪伴、安防。你已经有比较成熟的底层运动控制缺的是上层感知和任务规划能力。你在测量、数据采集、场景理解上有明确需求而不是只想做一个技术 demo。你愿意在日志、标定、数据留痕、异常处理这些工程环节上投入时间而不是只盯着模型精度。6.2 不适合什么反过来下面这些情况建议谨慎你需要在完全无 GPS 的开阔地面上做长距离、高精度定位。地面感知方案的里程计适合局部场景全局长距离还是需要额外的路标或高精度地图配合。你的场景物体变动极其频繁而且没有规律。比如天天换布局的仓库、堆满杂物的临时场地感知系统会很难维持稳定的地图和避障策略。你想不经过最小闭环直接上一堆传感器和模型。地面感知系统最怕“多而不稳”感知层越多标定和同步问题越严重。你没有日志系统全靠肉眼看现象猜问题。没有可观测性任何排查都会变成玄学。6.3 下一步最该做什么如果让我给一句话建议别急着上多传感器阵列也先别追求技术演示的“炸场”。找一个 20 平米的室内空间把最小闭环跑稳连续运行 10 次不出问题再用日志复盘每一次的细节差异你会发现整个系统的真实瓶颈在哪里。之后再去扩展语义识别、语音交互、平台管理、多机协同每一步都有清晰的基础支撑。这个顺序比追着热搜词走要稳妥得多。回到最开始那个命题空中感知技术的成熟给地面场景提供了一堆高质量的“零件”但零件不等于整车。真正的工程价值在于把这些零件重新适配到一个新的物理世界和工作流里。ROMO2 这类地面伙伴本质上是空中技术思维方式的一次换乘——从导航坐标系进入生活坐标系。谁先把这件事做顺谁才能真正让用户感到省心。