Each sensor on the drone has a fixed pose relative to base_link — the TF-Luna points straight down ~5 mm below the frame plane, the VL53L0X array sits in a ring around the perimeter at 60-degree intervals, the PMW3901 optical flow is mounted in the same downward-facing assembly as the TF-Luna. These pose offsets aren’t decorative — they’re load-bearing for SLAM and for sim-to-real transfer.
Current status: placeholder. The actual sensor mount geometry needs to be matched to the physical carrier board, which is on the H2 2026 roadmap. For now, the simulated mounts use approximate positions that are good enough for RL training in warehouse_v2 but will need recalibration once the physical board is fabricated.
Pose convention
Gazebo uses six-element poses: x y z roll pitch yaw (meters, radians) relative to the parent link. For sensor mounts:
<link name="tf_luna_link">
<pose>0 0 -0.005 0 1.5708 0</pose> <!-- 5 mm below base, rotated 90° to point down -->
<sensor name="tf_luna" type="gpu_lidar">
...
</sensor>
</link>
The 1.5708 rad (= 90°) pitch rotates the sensor’s local Z axis from “forward” (Gazebo default) to “down.”
Why pose matters
The policy was trained with sensors at specific poses. If the deployed drone has a sensor 2 cm forward of where the simulated drone has it, the rangefinder data looks subtly different — closer to nearby walls, farther from the floor — and the policy’s interpretation of “the drone is here” drifts. For RL sim-to-real, this is one of the easier transfer gaps to close (geometry is a known quantity), but it has to be done deliberately.
Where to go next
- iris_claudedrone customization — the model containing these mounts
- TF-Luna sensor — the physical sensor side
- 3-rangefinder sensor stack — the design rationale for the mount layout