HUA Smart Campus · Mobile Sensor Unit

A small robot that maps a room and tells you what the air is like in it.

A Duckietown DB21 Duckiebot carrying a LIDAR and an environmental sensor, driving a space on its own, building a 2D map with SLAM, and geotagging temperature, humidity, pressure and air quality to exactly where each reading was taken — validated across eight simulated environments and on real hardware.

Explore the 3D rooms View the code Read the report (PDF)

8simulated worlds

2SLAM backends compared

4env. readings per sample

The DB21 Duckiebot with the added RPLIDAR and environmental sensor mounted on the rear.

The DB21 with the RPLIDAR C1 and DFRobot SEN0335 environmental sensor added — purely additive to the stock chassis.

Overview

Stock hardware, three extra jobs.

Everything below is built on a completely standard Duckietown DB21. Two sensors are bolted on, and the robot's own software only ever adds capability on top of the platform Duckietown already ships — nothing stock is modified.

Sees the room

An RPLIDAR C1 spins 360°, feeding a SLAM algorithm (gmapping, tuned against hector_mapping) that builds a 2D occupancy map and tracks the robot's position inside it as it drives.

Covers it on its own

Frontier exploration discovers the room's shape, then a coverage-aware patrol sweeps the known-free floor in rows — or down the centreline in a corridor too narrow to sweep — so the sensor actually crosses the whole space, not just the area near where it started.

Geotags what it measures

A DFRobot SEN0335 (ENS160 + BME280) reads temperature, humidity, pressure and an air-quality index once a second. Every reading is stamped with the robot's map position at that instant and written to CSV.

How it works

One run, five stages.

The same pipeline runs whether the robot is real or simulated — only the sensor-facing nodes differ; every navigation and mapping node is identical code either way.

Initial scan

Stand still, take one LIDAR sweep, build a starting map.

Explore

Drive toward the nearest unmapped frontier until the map stops growing.

Plan a sweep

Lay out rows across the known floor, or a centreline in a narrow space.

Drive & log

Re-plan ~5×/second while driving; log every sensor reading, geotagged.

Save results

Map, actual path taken, and the CSV are pulled off before teardown.

Two independent safety layers run the entire time: a front-distance sensor feeds the path planner so it can route around close obstacles, and a last-resort veto refuses any forward command once something is too close — fail-closed, so a dead sensor stops the robot rather than silently permitting a collision. See the full report for the failure analysis this came out of.

Interactive

The eight Gazebo worlds, in 3D.

Every room below is reconstructed live in your browser from the project's actual Gazebo world files — the exact geometry the simulated robot is tested against, not a mockup. Drag to rotate, scroll to zoom.

drag to rotate · scroll to zoom

walls furniture railing robot (scale)

Rendered client-side with three.js, parsed directly from the project's .world SDF files — no server, no pre-baked 3D models.

Simulation results

Why coverage, not just exploration, matters.

Frontier exploration alone stops as soon as the map is complete — in an open room that can happen having barely moved the robot. The coverage-aware patrol that runs after it is what actually gets the sensor across the floor.

Map of the classroom world with only a handful of waypoints planned, exploration only. — Frontier exploration declares the map complete quickly, so almost no waypoints ever get planned near the far side of the room.

Map of the classroom world with a dense grid of waypoints across every row of desks, coverage-aware patrol. — The same world, patrol enabled: a waypoint down every row of desks, most of them reached (green).

Each map is the robot's own SLAM output with every planned waypoint marked — green where the robot actually reached it, amber where it didn't.

Map of a narrow corridor with very few waypoints planned, exploration only. — **Corridor — exploration only**Too narrow for a row-sweep to fit more than a couple of waypoints at all.

Map of a narrow corridor with waypoints spread along its centreline, coverage-aware patrol. — **Corridor — centreline patrol**Falls back to driving the corridor's centreline when a row-sweep would yield nothing.

Reconstructed temperature field compared against the known simulated ground truth. — **Field reconstruction**A genuine heatmap: in simulation the true field is known, so the recovered map can be scored directly against it.

Hardware validation

The same pipeline, on the real robot.

Every simulated node above has a real-hardware counterpart running literally the same navigation and mapping code. The real corridor is the harder case on purpose — long, narrow, and feature-poor, which stresses SLAM far more than an open room.

The real corridor used for hardware testing, looking along its length. — **The real corridor**The along-axis doors are what the corridor_real Gazebo world was built to reproduce.

Heatmap of temperature overlaid with the calculated route and the actual SLAM trace from a real run. — **Route + field, real run**Planned waypoints, the actual driven path, and the temperature field — all on one map.

Occupancy grid map with waypoints coloured by outcome from a real hardware run. — **Map + waypoint outcomes**Each waypoint coloured by whether the robot actually reached it.

Real hardware run, annotated

Dashboard footage of a real autonomous corridor run, with an on-screen HUD showing live sensor readings and event captions synced to the robot's own logged data.

Demo videos

Autonomous scans, five environments.

Gazebo GUI captures of complete, unattended autonomous runs — frontier exploration handing off to the coverage-aware patrol, in each of the project's simulated environments.