go2 lidar timestamps bugfix

[leshy]

GO2 webrtc stream has a bug with bizzare timestamps occasionally attached to lidar frames

this very simple hack corrects timestamps that are non monotonic because we know the expected lidar frequency

[greptile-apps]

Greptile Summary

This PR fixes two related timestamp bugs in the GO2 lidar pipeline: pointcloud2_from_webrtc_lidar now trusts the sensor's own stamp field (rather than falling back to wall-clock time.time()), and a new repair_stale_ts pipeable operator detects and corrects non-monotonic stamps by forward-extrapolating from the last known-good value.

• pointcloud2_from_webrtc_lidar: drops the time.time() fallback; the sensor stamp is now the authoritative source and the old comment calling it "broken" is removed.
• repair_stale_ts: new stateful ops.map operator that stores prev_good in a closure, rewrites any stamp ≤ prev_good to prev_good + default_period (130 ms default matching the expected lidar frequency), and logs a warning; applied in connection.py after the point-cloud conversion step.
• test_lidar.py: three new unit tests covering single stale frame, all-monotonic pass-through, and two consecutive stale frames.

Confidence Score: 5/5

Safe to merge — the change is a well-scoped, well-tested fix to a hardware timestamp quirk with no impact on unrelated subsystems.

The fix is narrow and correct: sensor stamps are now used as the authoritative source and a stateful forward-extrapolation operator repairs the rare stale frames. The three new unit tests cover the normal path, a single stale frame, and consecutive stale frames. In-place mutation of item.ts inside the map is safe here because pointcloud2_from_webrtc_lidar creates a fresh PointCloud2 object for every frame before it reaches repair_stale_ts, so no shared references exist upstream.

No files require special attention.

Important Files Changed

Filename	Overview
dimos/robot/unitree/type/lidar.py	Adds repair_stale_ts operator with a prev_good closure; switches pointcloud2_from_webrtc_lidar from time.time() to data["stamp"]. Logic is correct and well-encapsulated.
dimos/robot/unitree/connection.py	Wires repair_stale_ts() into lidar_stream() pipeline after pointcloud2_from_webrtc_lidar. One-line change with no other impacts.
dimos/robot/unitree/type/test_lidar.py	Adds three unit tests for repair_stale_ts covering monotonic, single stale, and consecutive stale frame scenarios. All assertions are correct.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[raw_lidar_stream\nWebRTC frames] --> B[ops.map\npointcloud2_from_webrtc_lidar\nuses data stamp]
    B --> C[repair_stale_ts\nops.map _repair]
    C --> D{item.ts <= prev_good?}
    D -- No\nmonotonic --> E[prev_good = item.ts\nemit unchanged]
    D -- Yes\nstale stamp --> F[item.ts = prev_good + 130ms\nlog warning\nprev_good = item.ts\nemit repaired item]
    E --> G[backpressure\ndownstream consumers]
    F --> G

Loading

_{Reviews (2): Last reviewed commit: "logger fix" | Re-trigger Greptile}