Title: Progress Update & Architecture Questions: clean-and-map (First Clean Coverage)

[Arkz-Deepak]

Hi everyone,

I am currently working on the clean-and-map package for the first-pass coverage and SLAM mapping as outlined in the RFC, and I wanted to share my progress, validate my architecture, and ask for some advice on a few Nav2 roadblocks I’ve hit.

Current Progress & Architecture

I have built a custom VacuumController state machine in C++ (oomwoo_clean_and_map) that runs in the Gazebo simulation.

To comply with the RFC's requirements for handling both standard walls and LiDAR-invisible objects, I’ve implemented a Hybrid Safety System:

1. Virtual Bumper (LiDAR): Scans the front, left, and right cones using /scan. It halts the robot at 0.45m to prevent physical collisions (which were causing odometry slip and messing up the SLAM map) and triggers a U-turn lane shift.

2. Physical Bumper (Fallback): Subscribes to /bumper_left and /bumper_right (ros_gz_interfaces/msg/Contacts). If the array size is > 0 (e.g., hitting a glass table), it overrides the LiDAR, forces an immediate reverse, and escapes 90 degrees away from the impact.

The Roadblocks & Doubts

I originally wanted to hand a hardcoded zig-zag waypoint plan directly to Nav2 using the NavigateThroughPoses action server.

However, because this is the first clean and the map is entirely unknown, the Nav2 GridBased planner immediately aborted the goal (Failed to plan... Unable to transform poses to global frame / The costmap cannot raytrace for it). Nav2 correctly refuses to drive blindly into grey, unmapped SLAM space.

Because of this, I fell back to a reactive open-loop approach:

• The robot drives forward blindly by publishing linear.x directly to /cmd_vel.

• When the LiDAR or Bumper detects an obstacle, it cuts cmd_vel power and hands control over to Nav2 (NavigateToPose) to calculate and execute the precise 180-degree lane shift.

• Once the turn succeeds, it resumes the open-loop sweep.

Advice Needed

1. Nav2 vs. Unknown Space: Is there a standard way within the OOMWOO stack to force Nav2 to accept coverage waypoints into unmapped space during the first SLAM pass, or is a reactive /cmd_vel sweep the preferred method for the initial exploration?

2. m-explore-ros2 Integration: The RFC mentions m-explore-ros2 for frontier exploration. Would you recommend relying entirely on m-explore to map the room first, and then running the coverage path, or should the boustrophedon (zig-zag) pattern be driving the initial map creation simultaneously?

3. Odometry Slip: When the robot makes physical contact with an object, the wheels sometimes slip before the Gazebo contact sensor registers, warping the SLAM map. Are there any specific Gazebo friction parameters or Nav2 costmap inflation radii you recommend tuning for the oomwoo_one robot to prevent this?

Any guidance on the preferred architecture for pushing into unmapped space would be highly appreciated!

[makers-pet]

Hi Arkz,

Nav2 vs Unknown space - Nav2 does drive into inknown space in my experience. Try doing this manually in makerspet/oomwoo:jazzy-dev living room world, see yhis tutorial step 9 https://makerspet.com/blog/simulate-oomwoo-one-robot-vacuum-in-gazebo-with-ros-2/

Use m-explore-ros2 to map entire house first vs start cleaning immediately - modern consumer vacuums typically start cleaning immediately. m-explore-ros2 is just a placeholder for a proper clean-and-map.

Virtual bumper 0.45m away from obstacles - good for delivery robot, but a vacuum routinely cleans along walls and in tight places.

Odometry slip - a real problem. I haven't looked at it carefully. SLAM is supposed to handle odometry slip, but that may not work after all.

At a brainstorming level, if I had to debug odometry slip, I'd try buffering data for a couple of seconds before handing it to SLAM (or discarding it when bumper gets hit and re-localizing). But maybe there is a better solution.