The LR-1BS5's angle scale runs clockwise viewed from the top, so
decoding it as CCW mirrored the whole world left/right — undetectable
with a single lidar (the SLAM map is self-consistently mirrored and
heading-vs-motion checks pass, since a mirror about x preserves
'ahead'). It surfaced when a second, right-handed lidar disagreed
(doubled walls), and the finished map came out mirrored versus the
actual room.
device_deg() now negates the raw angle BEFORE the model's 0°-reference
offset (LR-1BS5: out = 180 − raw), driven by model_angles_clockwise().
Evidence: field-verified on OLELR-1BS5 (2026-07-23), and DF Automation's
production ROS driver (github.com/dfautomation/ole2d, decoder.cpp)
walks the device array backwards with the comment 'reverse, laserscan
is anticlockwise' — its packet layout is exactly our Family B, so
LR-1FMI (same protocol) is listed too. Family A/C stay CCW until a
unit is verified against a real room.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Field-verified on an OLELR-1BS5 unit: with offset 0 the SLAM pose moved
correctly but the estimated heading came out 180° from the direction of
travel (the classic rotated-sensor-frame signature). The 1BS5 numbers
its angles from the rear like its LR-1F/LR-1FMI siblings, so it gets the
same angle_offset_deg = 180 so that driver output 0° = ahead.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
