What this is: A build-and-verify session: we created a new 12x12 meter “base stand” simulation world with corner pillars and a central room, then walked through every sensor mode the drone supports to confirm each one streams and behaves correctly. Why it’s here: A clean, repeatable test arena plus a documented pass/fail run of all sensors is the kind of foundation work that everything else stands on. If you ever wonder “do all the sensors actually work?”, this is the receipt.
Date: 2026-06-11 Ticket: Base stand world + sensor verification (machine D2, RTX 5070)
Glossary
A few plain-English definitions before we dive in.
- Base stand. Think of it as a model train set table, but for a drone. It is a fixed, known room in the simulator that we can drop the drone into again and again so every test starts from the same place. Our new base stand is 12 by 12 meters.
- Sensor mode. A drone carries several distance sensors. “Mode” just means how a given sensor is being used right now — for example, a beam pointed straight ahead and held still, versus a beam slowly swept side to side like a lighthouse. Same hardware, different behavior.
- SDF. The file format Gazebo uses to describe a world: where the walls are, how big the room is, where the pillars sit. It is just a structured text file, like a blueprint.
- Streaming sensor. A sensor that publishes readings continuously and automatically, the moment the simulation starts — you do not have to ask it for anything. Like a thermometer that always shows the temperature.
- Sweep. Mounting a small servo motor under a distance sensor and rotating it so the single beam scans across an arc, turning one forward reading into a fan of readings. Like sweeping a flashlight across a dark room to see what is there.
1. The new world: base_stand_12x12
We started from an existing 12x12 meter lab room (X and Y spanning from -6 to +6 meters, walls 2.5 m tall) and added the features Aleks asked for.
The four pillars. One box pillar in each corner, set 1.5 m in from the walls, so their centers land at (±4.5, ±4.5). Each pillar is 0.5 x 0.5 x 2.5 m and brown, matching the style of our earlier multi-pillar room. They give the sensors something solid to bounce off at known positions.
The central room. A 3 x 3 m room sits in the middle, formed by inner walls at ±1.5 m. It has a 1.0 m doorway in the center of three of its sides, and one fully solid side with no door. The solid side faces the red wall.
The red wall as a landmark. One outer wall is painted red and acts as a compass for anyone looking at the scene. It used to be called the “north wall,” but that name caused confusion with actual compass directions, so we renamed it wall_red. Now “the red wall” is an unambiguous reference point. The other walls keep neutral names.
Where the drone starts. The drone spawns at the center of the world, (0, 0, 0.2) — inside the central room. There is 1.5 m of clearance to the inner walls, comfortably more than the pre-arm proximity guard of 0.6 m, so the drone is happy to arm. To leave the room, it flies out through one of the doorways.
A couple of these are deliberate choices we left easy to flip later:
- The solid (doorless) side faces the red wall. To move it, you relocate the solid wall segment to another side and split the side it vacated into two door segments.
- The drone spawns inside the room by convention. If you would rather start it out in the open hall, you change one pose line.
- We did not add this world to the occupancy registry. That registry is only read by the navigation bridge at startup; the manual and sensor stacks pull walls straight from the live world, so they do not need it. If this world later needs the navigation bridge, adding a
room_size: [12.0, 12.0]entry is all it takes.
Validation. Running Gazebo’s built-in geometry checker (gz sdf --check) reported the geometry and XML as clean. (The checker also flags an inability to resolve the drone model path, but it does that identically on our known-good reference world too — it is a known limitation of the offline checker, not a problem with our file.)
Smoke test. We launched the world for real with GPU rendering. Gazebo’s model list reported all 16 models plus the drone loaded successfully: the floor, 4 outer walls, 4 pillars, the solid inner wall, 6 door-wall segments, and the drone itself. We captured an overview screenshot and a top-down layout diagram.
2. Verifying the sensor modes
With the world standing, we moved on to the real goal: confirm every sensor mode works. We launched the full stack with the GUI and let the drone sit on the ground — no flight needed, the sensors stream regardless.
Streaming sensors (always on)
These publish continuously the moment the simulation comes up.
| Sensor | Topic | Result |
|---|---|---|
| VL53 x6 | /mavros/vl53_ch0..5 (Range), /drone/vl53l0x/ch0..5 (LaserScan) |
~9.4 Hz. The mavros side caps at 1.20 m (its max range) when the drone sits in the center and walls are farther than 1.2 m away — correct behavior. The raw side reports inf (no return), which is exactly how a “nothing in range” reading should look. |
| TF-Luna (downward) | /drone/tf_luna_down (LaserScan) |
0.24 m — the drone’s height above the floor while resting on the ground. Spot on. |
| TF-Luna (forward beam) | /scan/sweep (LaserScan) |
9.1 Hz, ~5.9 m to the wall ahead. |
The headline here is that the “nothing in range” handling works: when there is genuinely no surface within reach, the sensors report inf instead of garbage.
Sweep modes
This is where the small servo motor comes in. It rotates the forward TF-Luna so its single beam can scan an arc. We tested five distinct modes, and all five passed.
| # | Mode | How | Result |
|---|---|---|---|
| 1 | Static 90° | Command the servo to a fixed angle | Beam holds steady at ~5.92 m straight ahead. |
| 2 | One-shot sweep | Trigger a single full pass | Node log: start, then done with 181 samples, min 5.89 m, max inf. One full pass takes ~24.9 s (it steps 1° every 120 ms). Progress goes from scanning to complete and the result is published. |
| 3 | Autoscan (live spawn) | Spawn an autoscan helper that drives the sweep on a trigger | The helper fires its trigger, the sweep node starts at the same timestamp, and a stop command cleanly halts it (“stop received, will not start a new one”). Idle-spawn plus resume/stop all behave. |
| 4 | Continuous triangle + data dump (live spawn) | Spawn a storage helper looping the sweep and saving readings | One cycle completed with 84 samples in 9.01 s and dumped a data file to disk. It ran on its own dedicated topics so it never collided with the main sweep node. With looping on, it would keep cycling. |
| 5 | Direct servo command | Drive the servo across its full range and watch the beam | The servo travels the whole arc and the beam tracks the angle: 0° reads 5.90 m, 45° reads 7.25 m, 90° reads 5.92 m, 135° reads inf, 180° reads 5.90 m. Those numbers are exactly the geometry of a square room seen from its center — the corners are farther (hence 7.25 m at 45°) and one angle sees only the open doorway (hence inf). |
All five sweep modes plus the streaming sensors passed, on both the reference world and the new base stand.
Notes and gotchas
A few things tripped us up that are worth writing down:
- The
/drone/vl53l0x/ch*topics are LaserScan messages (data lives in arangesarray), while/mavros/vl53_ch*are Range messages (data lives in a singlerangefield). Asking for the wrong field gives you nothing — easy to misdiagnose as a dead sensor. - Several status topics (sweep status, sweep result, triangle status) only publish on state transitions, not on a steady clock. So a one-shot listener fired between transitions just hangs and times out. For a GUI, the right move is a persistent subscription; for proof of state, the node’s own logs are authoritative.
- Listening once on an input topic that has no publisher yet (a target-angle command, for example) will hang forever. Wrap those probes in a hard timeout.
Artifacts
- The new world file:
src/drone_sim/worlds/base_stand_12x12.sdf(uncommitted at the time of writing, pending Aleks’s visual sign-off). - Media from the run:
sensor-verify-2026-06-11/—base_stand_overview.png,base_stand_layout.png(the top-down layout), andgz_sensor_verify.png.