OOMWOO 首次清洁ROS2 覆盖清扫 同步建图 边界探索clean-and-map RFC 全解析【免费下载链接】oomwooOpen-source vacuum robot cleaner项目地址: https://gitcode.com/gh_mirrors/oo/oomwoo本文围绕 OOMWOO 开源扫地机器人项目中的contributions/clean-and-map模块即 First Clean: coverage cleaning with mapping and exploration RFC展开系统讲解无地图启动 → 覆盖清扫 → SLAM 同步建图 → 边界探索直至完成的完整技术方案、鲁棒性要求、测试与验收标准并结合仓库中的接口契约文档与相邻模块设计进行纵深解读。读完本文你将掌握该模块的实现路径、可复用的 ROS2 主题/动作契约、覆盖路径规划Coverage Path Planning, CPP的模式取舍以及一套可量化、可 CI 回归的验收框架。一、模块定位为什么需要首次清洁OOMWOO 的软件栈采用模拟优先simulation-first的模块化开发方式见 docs/ARCHITECTURE.md每个模块都是可独立替换的 ROS2 包。clean-and-map承担的是整条软件链路中最具挑战性的场景之一机器人第一次进入一个完全未知的环境。该 RFC 定义的核心场景是机器人启动时没有任何地图no prior map使用**覆盖路径规划coverage path planning**清扫所有可到达的地面在清扫的同时通过 SLAM同步建图SLAM while cleaning而不是先建图再清扫的两趟式流程持续探索边界frontier exploration直到地图完整、可到达区域全部被覆盖检测到明确的完成条件done condition后保存地图供后续nav-localize模块在已知地图上导航复用。由于物理机器人尚未制造完成本模块当前的全部开发与验证都在Gazebo 仿真中完成依赖urdf-gazebo-sim提供的机器人 URDF、世界场景与保险杠传感器后续再在真机live-robot-bringup上复验。RFC 同时给出了一个立即可用的真机占位方案——通过 ROS2 接入 Proscenic M6 Pro 扫地机器人进行开发无需等待 OOMWOO 硬件。模块的完整贡献说明、步骤与验收标准位于 contributions/clean-and-map/README.md本文即以此为骨架展开。二、相邻模块与接口契约本模块在 ROS2 生态中的位置clean-and-map不是孤立的。RFC 明确列出了一组必须先行核对的相关模块对应仓库目录均为contributions/下模块职责与 clean-and-map 的关系nav-localize已知地图上的导航/定位/恢复消费本模块保存的地图支持未完成地图续建dock-cycle出坞/回坞/充电/驿站服务清扫任务中断后回坞充电再续扫recovery-safety恢复行为与安全恢复阶梯、e-stop本模块的碰撞恢复使用其基本局部恢复完整恢复阶梯在其模块内floor-care贴墙/边缘清扫、地毯/硬木识别、拖地覆盖清扫的边缘处理与其衔接cleaning-jobs清洁模式、分区、任务编排对本模块的覆盖进度进行分段编排、中断续扫urdf-gazebo-sim机器人 URDF、Gazebo 世界、保险杠本模块依赖其提供的机器人模型、世界与保险杠话题所有这些模块共享同一份软件接口契约docs/SOFTWARE_INTERFACES.md。它定义了模块间可复用的公共 ROS2 主题、动作与服务设计目标是模块可互换任何合规实现都可替换另一个模块只依赖发布接口而不依赖彼此内部实现。这份契约对clean-and-map而言意味着以下几个关键约定2.1 坐标帧REP-103SI 单位帧含义归属map全局地图帧SLAM/AMCL/Nav2 与保存的地图共用SLAM/定位odom局部连续里程计帧底盘里程计base_footprint导航用平面底盘帧机器人描述/里程计base_link机器人主体帧机器人描述base_scan2D LiDAR 帧机器人描述2.2 基线话题MVP 基线由 Gazebo 仿真或标准 Nav2/SLAM bringup 提供话题类型方向生产者消费者/cmd_velgeometry_msgs/msg/Twist命令遥控、Nav2 速度平滑器、恢复节点Gazebo 差速底盘/基座控制器/odomnav_msgs/msg/Odometry状态Gazebo 里程计/基座控制器SLAM、AMCL、Nav2、恢复与任务逻辑/tftf2_msgs/msg/TFMessage状态机器人状态发布器、里程计、SLAM/定位所有位姿感知模块/joint_statessensor_msgs/msg/JointState状态Gazebo 关节状态发布器/硬件底座机器人状态发布器、诊断/scansensor_msgs/msg/LaserScan传感器2D LiDAR/Gazebo LiDARSLAM、AMCL、Nav2 costmap、贴墙/mapnav_msgs/msg/OccupancyGrid状态SLAM 或地图服务器Nav2、清洁、分区、可视化/bumper_leftros_gz_interfaces/msg/ContactsGazebo 中传感器Gazebo 左侧接触传感器恢复、安全、clean-and-map 障碍处理/bumper_rightros_gz_interfaces/msg/ContactsGazebo 中传感器Gazebo 右侧接触传感器恢复、安全、clean-and-map 障碍处理对clean-and-map来说输入面是/scan、/odom、/tf、左右保险杠事件以及可选的 Nav2 动作输出面是首次覆盖清扫驱动 完整地图产出 完成条件判定 地图工件保存在契约表的模块接口中定义为clean-and-map消费/scan、/odom、/tf、bumper 事件与可选 Nav2 动作产出首次通过的覆盖清扫、完整地图、完成条件与地图保存。2.3 保险杠事件bumper events的解析约定仿真中保险杠话题的原始消息是ros_gz_interfaces/msg/Contacts字段结构为contacts列表每个 contact 含collision1、collision2、positions、normals、depths、wrenches。契约中有两条容易踩坑的明确约定消费者应将len(msg.contacts) 0过滤掉地面接触后视为一次保险杠事件不要读取collisions字段——它属于单接触消息类型不是桥接发布的内容。此外未来硬件可能将原始 Gazebo 接触消息替换为归一化后的保险杠消息硬件桥接草稿中对应/oomwoo/io/bumper位域话题见 contributions/io-board-interface 的 CPU/MCU 串口契约。因此在模块提交中应将 Gazebo 特有的解析逻辑隔离在一个小适配器adapter之后以便硬件定型时平滑替换。2.4 Nav2 接口复用RFC 强调尽量复用 Nav2 的动作与服务/navigate_to_posenav2_msgs/action/NavigateToPose单点导航/navigate_through_posesnav2_msgs/action/NavigateThroughPoses多点路径覆盖清扫、房间任务、回坞接近均适用Nav2 行为服务器spin、backup、drive_on_heading、wait恢复与局部兜底逻辑局部/全局 costmap 话题障碍处理、分区、诊断地图保存Map saver service/CLIclean-and-map与nav-localize共用。同时契约给出了一条纪律如果模块需要直接命令运动必须说明如何与 Nav2 及恢复节点仲裁避免两个节点争抢/cmd_vel。三、先例分析覆盖模式Prior Art与取舍RFC 按从最简单到最地图驱动的顺序梳理了业界常见的覆盖清扫策略随机游走 碰撞Random-walk bump——早期 Roomba 的做法靠统计覆盖、无地图简单、慢、会留下空隙。螺旋 / 回溯螺旋Spiral / backtracking-spiral——向外螺旋扩张螺旋闭合时回溯到未访问区域。trade-off边界附近容易留下空隙。牛耕式往复Boustrophedon / back-and-forth rows——清扫主力方案**牛耕式单元分解boustrophedon cellular decomposition**将自由空间切分为若干单元每个单元用简单行覆盖。OOMWOO 基于地图的清扫已采用此模式oomwoo_coverage工具。外围 内部Perimeter interior——先贴墙清扫边缘对应floor-care模块再对中部做牛耕式覆盖这是标准吸尘器组合拳。RFC 特别提示了预期代价螺旋模式在边界附近留缝牛耕式付出的是转向开销。无论采用哪种模式本 RFC 仍然拥有其独有的两个核心部分边扫边建图SLAM-while-cleaning与探索到完成为止的边界探索frontier-exploration-to-done。四、贡献指南从复现基线到覆盖清扫核心实操RFC 的 Request for Contribution 部分给出了可执行的分步指南这是本模块的实战骨架逐条展开如下。4.1 第一步先复现基线仿真按照 Gazebo 仿真搭建教程运行差速驱动 LiDAR机器人在Living Room 世界中跑通m-explore-ros2kaiaai fork做边界探索——它只建图探索、不清洁是验证建图与探索链路、为覆盖清扫打底的良好起点建立在urdf-gazebo-sim提供的机器人模型、世界与保险杠之上在项目 Discussions 中发帖说明自己正在做该模块并持续同步进度。从源码结构看urdf-gazebo-sim模块的贡献说明contributions/urdf-gazebo-sim/README.md提供了两个可直接启动的仿真世界kitchen_dining与living_room启动命令形如ros2 launch oomwoo_gazebo world.launch.py world:living_room.worldSOFTWARE_INTERFACES.md还给出了一组可用于验证基线接口是否就绪的检查命令ros2 topic list ros2 topic echo /scan --once ros2 topic echo /odom --once ros2 topic echo /bumper_left ros2 topic echo /bumper_right ros2 run tf2_tools view_frames对于基于 Nav2 的模块还要求文档说明如何发送NavigateToPose目标、如何确认/cmd_vel仲裁安全。4.2 第二步加入覆盖清扫coverage cleaning这是模块的核心功能增量RFC 拆成五个子要求无地图启动机器人以无先验地图状态启动覆盖路径规划与执行规划并执行覆盖全可到达地板的路径如牛耕式往复外加角落与墙边处理边扫边建图用 SLAM如 slam_toolbox 或 Cartographer在清扫的同时建图——建图与清扫同步进行而不是分开两趟持续边界探索直到地图完整为止持续探索前沿frontier保证不遗漏任何可到达区域明确完成条件并保存地图定义并文档化清晰的 done 条件全覆盖 且 地图完整然后保存地图。4.3 第三步鲁棒性make it robust该模块必须处理的三大类脏活动态障碍人、宠物或物体进入机器人行进路径时不得破坏覆盖或建图——机器人应重新规划并继续LiDAR 不可见的静态障碍LiDAR 可能把机器人实际无法到达的区域报告为开阔地板玻璃、LiDAR 扫描平面以下的物体、门槛、台阶边缘。必须通过保险杠接触检测这类障碍将其标记为障碍物恢复并绕行保险杠事件响应对urdf-gazebo-sim保险杠发布的左开关、右开关、前保险杠事件做出正确反应永不永久卡死能从碰撞和楔入wedged状态中恢复——本模块只需一个基本局部恢复完整的恢复阶梯属于recovery-safety模块。这里与recovery-safety的设计方向形成了清晰分工recovery-safety的 RFCcontributions/recovery-safety/README.md指出真实扫地机器人不能用Nav2 的spin/backup逃生——它们是避碰的会检查 costmap 并拒绝进入机器人恰好楔入的栅格从而在最需要时停摆。吸尘器是可接触的有保险杠、本来就允许触碰墙壁家具它需要的恢复是一层小的、反应式的、由保险杠驱动、开环运行并忽略 costmap 的行为层位于规划器之下并在接触时覆盖它即 Brooks 1986 的包容式架构 subsumption。可参考的逃生启发式来自 iRobot 多模式覆盖专利阈值需在仿真中调参包括楔入——保险杠持续受压若保险杠受压约 5 秒朝受压侧的反方向转动panic turn并重试直到释放后退并转向自由侧而不是盲目直线倒车被困口袋——频繁碰撞跟踪两次碰撞间的行驶距离低于阈值说明被围困切换为保险杠贴边跟随轻触、小角度进/退蠕行脱困低于更低阈值则 panic-turn卡死/轮子空转——无碰撞长时间无碰撞却行驶很远说明被架空或空转先螺旋仍无接触则 panic-turn不再重入把逃出的口袋标记为禁区避免清扫/补漏路径直接再钻回去。这些启发式的共性在于全部以保险杠模式bumper pattern为键而不是 costmap。4.4 第四步充分测试RFC 对测试提出了明确且可量化的要求从多种初始位置启动机器人验证仍能达到全覆盖与完整地图增加回归测试无头、CI 友好同时验证两件事地图完整性——构建的地图覆盖全部可到达区域覆盖完整性——清扫路径覆盖全部可到达地板测试从动态障碍与保险杠撞上 LiDAR 不可见障碍两种情况下的恢复能力。4.5 第五步额外 Gazebo 世界高价值项创建并测试更多世界多房间、不同户型、窄通道、家具、LiDAR 不可见障碍将这些世界回馈给仓库——它们能帮助所有人测试。4.6 第六步提交 PR将 PR 提交到contributions/clean-and-map/your-github-username/目录内容包括ROS2 包链接安装/运行/配置/故障排查/测试结果的说明文档新增的 Gazebo 世界多个起始位姿下的完整 clean-and-map 运行视频在 Discussions 中公布提交然后进入评审迭代RFC 本身标注 TBD预期会持续演进。五、验收标准Acceptance Criteria可量化、可复现RFC 给出了客观、可测量的验收条目这些标准同时是评审者筛选候选方案的依据在Living Room 世界、无地图启动、多个初始位姿下机器人对可到达地板实现全覆盖构建可到达区域的完整地图检测到清晰的完成条件并保存地图对动态障碍鲁棒——路径中的移动障碍不破坏覆盖或建图对LiDAR 不可见静态障碍鲁棒——检测到保险杠接触、标记并避开障碍、重新规划且不卡死对左/右/前保险杠事件反应正确回归测试通过同时验证地图完整性与覆盖完整性且可在 CI 中无头运行在至少一个额外的多房间/不同户型世界中工作有文档、且可被他人可靠复现其余标准 TBD随 RFC 演进。RFC 还特别说明维护者按这些标准在合规候选者中择优即使未被选中多次尝试也是有价值且有帮助的——模块是可替换的未选中的设计依然是有效的学习练习和回退方案。六、社区实施现状一个参照实现仓库中已有一个参照实现指针contributions/clean-and-map/Arkz-Deepak/README.md。它记录了实际贡献者采用的分阶段策略先做一个只清洁 MVPclean-only基于已有地图先把覆盖路径规划CPP逻辑在回归测试上拿高分再引入同步 SLAM阶段清单包括自托管仓库与指针 PR已完成→ 在已知地图上建立基础 CPP 节点 → 通过coverage_regression.launch.py测试装置 → 集成同步建图SLAM→ 处理保险杠边界情况与 LiDAR 不可见障碍进行中。这印证了 RFC 的路线图contributions/README.md的 RFC 看板contributions/README.md将该模块当前进度标记为 15%——覆盖计数器 回归测试装置 定点清洁drive-to-goal cleaning已就绪边覆盖边建图coverage-while-mapping尚未启动属于可立即开工的模块。七、开发环境约定与提交注意事项结合 docs/SOFTWARE_INTERFACES.md 与仓库约定参与本模块开发时还需遵守use_sim_time应为 true仿真 launch 文件必须开启传感器流如/scan在可配置处使用 sensor-data QoS/map与保存地图元数据应支持 transient-local 持久化以便**后加入者late joiner**获取命令话题应使用小队列并故障安全过期命令不得让机器人继续运动将 ROS2 包放入/ros_ws/src不要在~/下另建 colcon 工作区遵循通过kaia config robot.model oomwoo_one选择机器人包的约定。八、小结为什么这个模块值得认真对待clean-and-map是 OOMWOO 全栈软件中打通未知环境 → 可用地图闭环的关键一环它把三类成熟技术覆盖路径规划、SLAM 同步建图、边界探索揉进一个真实产品场景并用保险杠驱动的接触式鲁棒性与双完整性地图 覆盖回归测试把能用提升到可验收、可复现。其价值体现在接口清晰依赖完全建立在SOFTWARE_INTERFACES.md的公共话题/动作契约上模块可整体替换边界明确与nav-localize消费地图、recovery-safety完整恢复阶梯、cleaning-jobs任务编排续扫等模块各司其职不越界测试先行多初始位姿 无头 CI 回归 多世界验证让全覆盖 完整地图成为可量化的客观指标门槛友好纯 Gazebo 仿真即可开工真机占位方案Proscenic M6 Pro也已就绪任何贡献者都可以立即上手。如果你准备参与 OOMWOO 社区开发clean-and-map正是一个进度明确、验收清晰、仿真可测的绝佳起点——从复现基线仿真开始按 RFC 的分步指南推进最终在contributions/clean-and-map/your-github-username/下提交你的实现即可。【免费下载链接】oomwooOpen-source vacuum robot cleaner项目地址: https://gitcode.com/gh_mirrors/oo/oomwoo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
