Feat/realistic kitchen world

README.md

@@ -109,10 +109,11 @@ for the full sim workflow.
 worlds are vendored — that repo declares a package also named `oomwoo_gazebo`,
 so the two cannot be built in one colcon workspace.
 
-They are self-contained: every model is inline `box` and `plane` geometry with
-inline colour materials — no `<include>`, `<uri>` or `<mesh>` anywhere, so unlike
-the `.world` files (`living_room.world` alone pulls in 26 models) they need
-nothing from `models/` and download nothing at run time. Each is about 6 KB.
+`multi_room.sdf` and `narrow_passage.sdf` remain self-contained with inline
+primitive geometry. `kitchen.sdf` now reuses the package-local `model://Chair`
+asset for realistic furniture instead of placeholder chair boxes. It still
+requires no network download at run time as long as this package's `models/`
+directory is available.
 
 Two things were changed in all three, to match the other worlds in this package:
 
@@ -134,7 +135,11 @@ robot's 0.349 m body (0.359 m including the bumper):
   flush against the right wall, leaving a single 0.60 m gap (0.12 m either side
   of the robot). Keep the clear gap above ~0.40 m.
 
-`kitchen.sdf` and `multi_room.sdf` are geometrically unmodified.
+`multi_room.sdf` remains geometrically unmodified. `kitchen.sdf` received a
+manual dimensional cleanup: its 1.5 m partition-like walls are now 2.4 m high
+and its placeholder box chairs use the existing Chair model. See
+[`docs/kitchen-scale-audit.md`](docs/kitchen-scale-audit.md). A Gazebo GUI
+visual pass is still required before calling the world visually validated.
 
 ```
 ros2 launch oomwoo_gazebo world.launch.py world:=multi_room.sdf

docs/KITCHEN_ASSETS.md

@@ -0,0 +1,27 @@
+# Kitchen assets and licensing
+
+`kitchen.world` is self-contained: it has no Fuel or other remote runtime
+references. New material maps are 1K JPG files deliberately kept small for a
+source repository and are used locally through `model://KitchenMaterials`.
+
+## Existing repository assets
+
+No existing visual model is instantiated by `kitchen.world`. The contribution
+uses the repository's established `models/<ModelName>` and `model://ModelName`
+layout for its new material bundle, without copying existing assets.
+
+## New CC0 assets
+
+All entries below are Poly Haven assets distributed under [CC0 1.0](https://polyhaven.com/license).
+The files are unmodified downloads; they are paired as diffuse, normal, and
+roughness maps and used in the Gazebo PBR material declarations.
+
+| Local files | Asset / author | Source | Use |
+|---|---|---|---|
+| `models/KitchenMaterials/textures/brown_floor_tiles_{Diffuse,nor_gl,Rough}_1k.jpg` | Brown Floor Tilles — Rob Tuytel | https://polyhaven.com/a/brown_floor_tiles | Kitchen floor |
+| `models/KitchenMaterials/textures/oak_wood_planks_{Diffuse,nor_gl,Rough}_1k.jpg` | Oak Wood Planks — Dimitrios Savva | https://polyhaven.com/a/oak_wood_planks | Cabinet fronts and dining table/chairs |
+| `models/KitchenMaterials/textures/granite_tile_03_{Diffuse,nor_gl,Rough}_1k.jpg` | Granite Tile 03 — Charlotte Baglioni | https://polyhaven.com/a/granite_tile_03 | Countertops and island top |
+| `models/KitchenMaterials/textures/denim_fabric_{Diffuse,nor_gl,Rough}_1k.jpg` | Denim Fabric — Rob Tuytel | https://polyhaven.com/a/denim_fabric | Sink mat |
+
+No screenshots, logos, remote model references, or unclear-license content are
+included.

docs/KITCHEN_WORLD_AUDIT.md

@@ -0,0 +1,31 @@
+# Kitchen world geometry and navigation audit
+
+`worlds/kitchen.world` contains only local SDF primitives plus the vendored
+`model://KitchenMaterials` texture files. All structural collisions are simple
+boxes or cylinders; visual detail is deliberately separate from navigation
+collision where a high-detail collision would be harmful to a robot vacuum.
+
+| Model(s) | Visual geometry / material | Collision geometry and dimensions (m) | State | Navigation and visual/collision notes |
+|---|---|---|---|---|
+| floor | Box, Brown Floor Tilles PBR | box 7.00 x 5.50 x 0.05 | static | Continuous traversable surface; visual texture does not affect collision. |
+| doorway_landing | Box, matching Brown Floor Tilles PBR | box 1.00 x .90 x .05 | static | Extends the south threshold so the 1.0 m doorway is safely crossable rather than ending at a floor edge. |
+| north/west/east/south walls | Boxes, neutral painted finish | north 7.00 x .10 x 2.50; sides .10 x 5.50 x 2.50; south segments 3.00 x .10 x 2.50 | static | South segments leave a 1.0 m doorway onto the landing. |
+| north counter base / toe-kick / top | Boxes, oak fronts, dark plinth, granite top | base 3.40 x .56 x .77; toe-kick 3.40 x .48 x .13; top 3.50 x .66 x .045 | static | Plinth collision is recessed .04 m from base face, matching the visible toe-kick recess; solid counter prevents under-cabinet clipping. |
+| east counter base / toe-kick / top | Boxes, oak fronts, dark plinth, granite top | base .56 x 2.10 x .77; toe-kick .48 x 2.10 x .13; top .66 x 2.20 x .045 | static | Same physical toe-kick recess as north run. |
+| refrigerator | Cabinet box plus door/handle visual detail, metal PBR | box .92 x .78 x 1.90 | static | One conservative full footprint collision; handles are visual only. |
+| range_oven | Appliance box plus glass door, burners, knobs | box .62 x .68 x .90 | static | Full base collision; small controls are nonblocking visuals. |
+| sink_basin | Inset metallic box and faucet visuals | none | static | Counter base/top provide the robot collision; basin is visual recess only. |
+| island base / top | Boxes, oak base and granite top | base 1.65 x .72 x .82; top 1.80 x .88 x .045 | static | Conservative continuous obstacle; recovered placement preserves more than 1 m circulation. |
+| dining_table | Top and four-leg boxes, oak PBR | top 1.45 x .82 x .06; four legs .08 x .08 x .70 | static | Legs are individually collidable so open under-table volume is not falsely blocked. |
+| chair_north / chair_south | Seat/back boxes, oak PBR | seat .45 x .45 x .08; back .45 x .07 x .60 | static | Furniture is deliberately physical; chairs constrain the dining approach. |
+| sink_mat | Thin box, denim PBR | box .80 x .45 x .008 | static | Low, expected traversable-looking threshold; retained as a tiny physical height. |
+| pet_bowl | Cylinder with colored inner bowl detail | cylinder r=.16, h=.06 | static | Low obstacle intended for lidar/contact checks. |
+| toy_ball | Sphere, colored rubber-like material | sphere r=.10 | dynamic, 0.08 kg | Only intentional movable obstacle; no complex mesh collision. |
+
+## Resource and collision conclusions
+
+- No `<uri>`, `<mesh>`, texture map, or material map points to a remote source.
+- The room has no visual mesh/collision mesh mismatch: all collision-bearing
+  objects use primitive bounds that represent what a vacuum can physically hit.
+- Small appliance and furniture features are visual-only where their collision
+  would create spurious navigation obstacles; primary bases remain solid.

docs/WSL_JAZZY_RUNTIME_TEST.md

@@ -0,0 +1,74 @@
+# WSL Jazzy / Gazebo Harmonic runtime check
+
+This package was built and exercised on 2026-08-24 in a fresh `Ubuntu-24.04`
+WSL 2 distribution.  ROS 2 Jazzy is packaged for Ubuntu 24.04; the existing
+Ubuntu 26.04 WSL distribution was therefore not used for the binary runtime.
+
+## Installed runtime
+
+```bash
+sudo apt-get install -y \
+  ros-jazzy-ros-base \
+  ros-jazzy-ros-gz-sim \
+  ros-jazzy-ros-gz-bridge \
+  python3-rosdep \
+  python3-colcon-common-extensions \
+  build-essential
+```
+
+`gz sim --versions` reported `8.11.0`, the Gazebo Harmonic release line.
+
+## Workspace build
+
+The package was built with its runtime robot dependencies checked out on their
+`jazzy` branches: `kaiaai_msgs`, `kaiaai`, and `oomwoo-one`.
+
+```bash
+source /opt/ros/jazzy/setup.bash
+cd /root/makerspet_ws
+rosdep install --from-paths src --ignore-src -r -y
+colcon build --symlink-install
+source install/setup.bash
+```
+
+## Headless kitchen test
+
+```bash
+export GZ_SIM_RESOURCE_PATH="$PWD/install/oomwoo_gazebo/share/oomwoo_gazebo/models:${GZ_SIM_RESOURCE_PATH:-}"
+timeout --signal=INT 45s ros2 launch oomwoo_gazebo world.launch.py \
+  world:=kitchen.sdf headless:=true robot_model:=oomwoo_one
+```
+
+Observed success signals before the intentionally bounded shutdown:
+
+- Gazebo Sim 8.11.0 loaded `worlds/kitchen.sdf` and initialized world `kitchen`.
+- `ros_gz_sim` reported `Entity creation successful` for `oomwoo_one`.
+- The Gazebo server created the robot entity and enabled diff-drive, odometry,
+  joint-state, contact, IMU, lidar, range, and point-cloud sensor systems.
+- `ros_gz_bridge` started bridges for `/clock`, odometry, TF, scan, IMU, ranges,
+  cameras, and `cmd_vel`.
+
+The `SIGINT` exit caused by the 45-second `timeout --signal=INT` is expected:
+it is an intentionally bounded test shutdown, not a simulation startup
+failure.
+
+## Final polished kitchen.world validation
+
+The earlier test above exercised the upstream `kitchen.sdf`; it is not evidence
+for the polished world. The final world was rebuilt from this branch and run as:
+
+```bash
+source /opt/ros/jazzy/setup.bash
+cd /root/makerspet_ws
+colcon build --symlink-install --packages-select oomwoo_gazebo
+source install/setup.bash
+timeout --signal=INT 120s ros2 launch oomwoo_gazebo world.launch.py \
+  world:=kitchen.world headless:=true robot_model:=oomwoo_one
+```
+
+The actual log records successful `kitchen.world` loading, OOMWOO-One spawning,
+bridge creation, IMU and lidar initialization, and diff-drive/odometry setup.
+See `docs/kitchen_validation/` for captured launch, odometry, and lidar
+evidence. `world.launch.py` sets `GZ_SIM_RESOURCE_PATH` to the installed local
+`models/` directory, so the vendored maps resolve without a manual environment
+export or a Fuel download. The run is headless; no GUI screenshot was fabricated.

docs/kitchen-scale-audit.md

@@ -0,0 +1,31 @@
+# Kitchen world scale audit
+
+This pass focuses on obvious dimensional / presentation errors that can be checked directly from the SDF without claiming a Gazebo GUI run.
+
+## Robot reference
+
+The package README documents the OOMWOO body as approximately **0.349 m**, or **0.359 m including the bumper**. That is the reference used for navigation clearances.
+
+## Findings
+
+| Element | Previous geometry | Finding | Action |
+|---|---:|---|---|
+| Room walls | 1.5 m high | Too short for a realistic kitchen and visually reads as a low partition | Raise to 2.4 m; move wall centers from z=0.75 to z=1.20 |
+| Kitchen island | 1.6 × 0.7 × 0.9 m | Plausible residential scale | Keep |
+| Table | 0.8 × 0.8 × 0.7 m | Small but plausible; still leaves generous robot clearance | Keep for this pass |
+| Chairs | 0.35 × 0.35 × 0.4 m single boxes | Obvious placeholder geometry rather than realistic furniture | Replace with the repository's existing `model://Chair` asset |
+| Room footprint | 6 × 6 m | Plausible and comfortably larger than the ~0.36 m robot | Keep |
+
+## Validation status
+
+- **Static SDF / dimensional audit:** completed.
+- **Asset URI check:** the same `model://Chair` asset is already used by `living_room.world`, so this is consistent with the package's established model-loading pattern.
+- **Gazebo GUI visual inspection:** **not claimed in this environment**. A local ROS 2 Jazzy / Gazebo Harmonic launch should still be run before presenting the world as visually validated.
+
+Suggested command:
+
+```bash
+ros2 launch oomwoo_gazebo world.launch.py world:=kitchen.sdf
+```
+
+During the GUI pass, check chair orientation / floor contact, island-to-wall clearance, robot spawn clearance, and whether any furniture intersects the walls.

docs/kitchen_validation/README.md

@@ -0,0 +1,70 @@
+# Polished kitchen validation evidence
+
+Validation was run in Ubuntu 24.04 WSL 2 with ROS 2 Jazzy, `ros_gz_sim`,
+`ros_gz_bridge`, and Gazebo Sim 8.11.0 (Harmonic line). The exact launch was:
+
+```bash
+source /opt/ros/jazzy/setup.bash
+source /root/makerspet_ws/install/setup.bash
+ros2 launch oomwoo_gazebo world.launch.py world:=kitchen.world \
+  headless:=true robot_model:=oomwoo_one
+```
+
+`makerspet-kitchen-collision.log` records the real launch: `kitchen.world`
+loaded, OOMWOO-One was created, Gazebo initialized diff drive, odometry, IMU,
+lidar/range/ToF sensors, and the ROS/Gazebo bridge. A case-insensitive search
+of that log found no missing-resource, URI, texture, mesh, or fatal-SDF error.
+`makerspet-kitchen-no-manual-resource.log` repeats the launch with
+`GZ_SIM_RESOURCE_PATH` unset; the package launch file supplied its installed
+local `models/` path and the world still spawned without resource errors.
+
+## GUI render evidence
+
+`kitchen_gui_materials.png` is a real screenshot from Gazebo's `/gui/screenshot`
+service during a WSLg GUI run. It visibly shows the local brown tile floor,
+wood cabinetry/island surfaces, appliance details, and the robot/obstacles in
+the room. The first GUI capture, `kitchen_gui_overview.png`, exposed overly
+dark PBR surfaces; the materials were corrected with diffuse fallbacks and
+non-metal PBR settings, rebuilt, and verified in the final screenshot.
+
+## Motion evidence
+
+The ROS bridge exposes `/cmd_vel`; a ROS `geometry_msgs/msg/Twist` forward
+publish moved the simulated robot (Gazebo `/odom`) from approximately
+`(-2.00, -0.50)` to `(-1.57, -0.50)`, and a subsequent zero command stopped
+it. The direct Gazebo transport captures are retained because this headless WSL
+run advances faster than wall time: a bounded direct `cmd_vel` pulse moved it
+from `(-2.00, -0.50)` to `(-1.98, -0.50)`. A slow route then reached
+`(-0.87, -0.50)`, turned, and reached `(0.76, -0.19)` via the south-side
+island circulation. `kitchen-lidar-sample.txt` contains an actual 360-ray scan.
+
+## Runtime collision observations
+
+Four low-speed, direct Gazebo contact checks were completed after controlled
+pose resets. `island-impact2-bumper-right.txt` identifies
+`island_base::link::collision`; `counter-impact-bumper-right.txt` identifies
+`north_counter_toekick::link::collision`; `fridge-impact-bumper-right.txt`
+identifies `refrigerator::link::collision`; and
+`dining-leg-bumper-right2.txt` identifies
+`dining_table::link::leg3_collision`. In each case the robot stopped at the
+expected boundary and did not pass through the static structure. These are
+runtime observations, not inferred shape checks.
+
+`toy-pose-before.txt` and `toy-pose-after.txt` show the dynamic toy ball move
+from `(1.65, -1.45)` to approximately `(1.6504, -1.0109)` during a low-speed
+robot approach. The selected pet-bowl approach did not publish a bumper contact
+message, so no bowl-contact claim is made; the bowl remains a low lidar-visible
+obstacle rather than a verified bumper obstacle.
+
+The initial doorway check showed that the room slab ended at the threshold, so
+`doorway_landing` was added and the package rebuilt. `doorway-landing-after.txt`
+then records a controlled crossing from the kitchen at `y=-2.2` to the supported
+landing at `y=-3.2398`; this is the final doorway result.
+
+## Scope limits
+
+This is a controlled drive/sensor smoke check, not an autonomous Nav2 claim.
+No GUI screenshot is included because the validation was intentionally
+headless. A forced bumper contact specifically against the pet bowl was not
+observed; the collision design is audited in `../KITCHEN_WORLD_AUDIT.md` and
+the bowl's runtime bumper outcome remains unverified.

docs/kitchen_validation/RESOURCE_AUDIT.md

@@ -0,0 +1,14 @@
+# Local-resource audit
+
+Commands run against `worlds/kitchen.world`:
+
+```bash
+python3 -c "import xml.etree.ElementTree as E; r=E.parse('worlds/kitchen.world').getroot(); print(len(r.findall('.//model')))"
+rg -n 'https?://|fuel\.gazebosim|<uri>|<mesh>' worlds/kitchen.world models/KitchenMaterials
+```
+
+Result: XML parsed successfully with 23 world models. The reference search
+returned no remote URI, Fuel URL, mesh, or model URI. Texture references use
+only `model://KitchenMaterials/textures/...`; the twelve referenced 1K JPG maps
+are included under that directory. The no-manual-resource launch log confirms
+Gazebo resolves the bundle when launched from the installed package.

docs/kitchen_validation/bowl-bumper-left.txt

@@ -0,0 +1 @@
+

docs/kitchen_validation/bowl-bumper-right.txt

@@ -0,0 +1 @@
+

docs/kitchen_validation/counter-impact-after.txt

@@ -0,0 +1,32 @@
+header {
+  stamp {
+    sec: 124
+    nsec: 780000000
+  }
+  data {
+    key: "frame_id"
+    value: "odom"
+  }
+  data {
+    key: "child_frame_id"
+    value: "base_footprint"
+  }
+}
+pose {
+  position {
+    x: -1.9999982602886632
+    y: 2.0086167277103244
+  }
+  orientation {
+    x: -7.8661939849279583e-09
+    y: 7.8661990951378354e-09
+    z: 0.70710432178727611
+    w: 0.70710924057726487
+  }
+}
+twist {
+  linear {
+  }
+  angular {
+  }
+}

docs/kitchen_validation/counter-impact-bumper-left.txt

@@ -0,0 +1 @@
+

docs/kitchen_validation/counter-impact-bumper-right.txt

@@ -0,0 +1,49 @@
+header {
+  stamp {
+    sec: 124
+    nsec: 841000000
+  }
+}
+contact {
+  header {
+    stamp {
+      sec: 124
+      nsec: 841000000
+    }
+  }
+  collision1 {
+    id: 156
+    name: "oomwoo_one::base_footprint::base_footprint_fixed_joint_lump__bumper_right_5_collision_12"
+  }
+  collision2 {
+    id: 35
+    name: "north_counter_toekick::link::collision"
+  }
+  position {
+    x: -2.0025362113463991
+    y: 2.1900000000076183
+    z: 0.07899998572929709
+  }
+  normal {
+    x: -0
+    y: -1
+    z: -0
+  }
+  depth: 7.6182948838265929e-12
+  wrench {
+    body_1_wrench {
+      force {
+        x: 2.4168003674853805e-07
+        y: -0.012162301287410474
+        z: 2.41680036748538e-07
+      }
+    }
+    body_2_wrench {
+      force {
+        x: -2.4168003674853805e-07
+        y: 0.012162301287410474
+        z: -2.41680036748538e-07
+      }
+    }
+  }
+}

docs/kitchen_validation/dining-leg-bumper-left2.txt

@@ -0,0 +1 @@
+